Bugzilla Bug 115189

Ebuild for torque-2.0.0p2 based on torque-1.2.0_p5-r1.ebuild

These two patches are now in torque 2 so no longer need to patch :)
http://www-rcf.usc.edu/~garrick/torque-1.2.0p5-jobnanny.patch
http://www-rcf.usc.edu/~garrick/torque-1.2.0p5-jobdepterm2.patch"

I also made new patches for 2.0.0p2 based on oldones
respect-ldflags.patch.gz
respect-destdir.patch.gz
destdir-fixes.patch
setuid-safety.patch

Created an attachment (id=74493) [edit]
new ebuild for torque 2.0.0p2

fix patch files location 

Created an attachment (id=74494) [edit]
destdir-fixes.patch adapted for 2.0.0p2

Created an attachment (id=74495) [edit]
respect-destdir.patch adapted for 2.0.0p2

Created an attachment (id=74496) [edit]
respect-ldflags.patch adapted for 2.0.0p2

Created an attachment (id=74497) [edit]
setuid-safety.patch adapted for 2.0.0p2

Latest is torque-2.0.0p4.tar.gz

*** Bug 114922 has been marked as a duplicate of this bug. ***

Who's tested this? Please report on how it works and any bugs you've
encountered.

Cannot make digest from the ebuild. I keep getting index.html page downloaded
to /usr/portage/distfiles although have downloaded the source tar.gz myself.

Lukasz, would you please check that?

Created an attachment (id=77469) [edit]
Fixed ebuild 

Fixed ebuild for torque-2.0.0p2 - previous one contained silly typo - sorry for
that.

download patches and put it to ./files directory in sys-cluster/torque
then ebuild ./torque-2.0.0p2.tar.gz digest 

should go clearly.

Please Test. On the weekend I'll update to newest torsmo2.0.0p5

Hi, probably I am a desperate user:

vrapenec torque # ebuild torque-2.0.0_p2.ebuild digest
torque-2.0.0p2
>>> Generating digest file...
<<< torque-2.0.0p2.tar.gz
>>> Generating manifest file...
<<< files/digest-torque-2.0.0_p2
<<< files/torque-2.0.0_p2-destdir-fixes.patch
<<< files/torque-2.0.0_p2-respect-destdir.patch.gz
<<< files/torque-2.0.0_p2-respect-ldflags.patch.gz
<<< files/torque-2.0.0_p2-setuid-safety.patch
<<< torque-2.0.0_p2.ebuild
>>> Computed message digests.

vrapenec torque # emerge torque
Calculating dependencies ...done!
>>> emerge (1 of 1) sys-cluster/torque-2.0.0_p2 to /
torque-2.0.0p2
>>> checksums files   ;-) torque-2.0.0_p2.ebuild
>>> checksums files   ;-) files/torque-2.0.0_p2-destdir-fixes.patch
>>> checksums files   ;-) files/torque-2.0.0_p2-respect-destdir.patch.gz
>>> checksums files   ;-) files/torque-2.0.0_p2-respect-ldflags.patch.gz
>>> checksums files   ;-) files/torque-2.0.0_p2-setuid-safety.patch
>>> checksums files   ;-) files/digest-torque-2.0.0_p2
>>> checksums src_uri ;-) torque-2.0.0p2.tar.gz
torque-2.0.0p2
torque-2.0.0p2
>>> Unpacking source...
>>> Unpacking torque-2.0.0p2.tar.gz to /var/tmp/portage/torque-2.0.0_p2/work

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 * 
 *  
/var/tmp/portage/torque-2.0.0_p2/distdir/torque-2.0.0_p2-respect-ldflags.patch.gz
 *   ( torque-2.0.0_p2-respect-ldflags.patch.gz )


!!! ERROR: sys-cluster/torque-2.0.0_p2 failed.
!!! Function epatch, Line 207, Exitcode 0
!!! Cannot find $EPATCH_SOURCE!
!!! If you need support, post the topmost build error, NOT this status message.

vrapenec torque # ls /usr/portage/distfiles/torque-*
/usr/portage/distfiles/torque-1.2.0_p1-respect-destdir.patch.gz 
/usr/portage/distfiles/torque-1.2.0p5.tar.gz
/usr/portage/distfiles/torque-1.2.0_p1-respect-ldflags.patch.gz 
/usr/portage/distfiles/torque-2.0.0_p2.tar.gz
/usr/portage/distfiles/torque-1.2.0p5-jobdepterm2.patch         
/usr/portage/distfiles/torque-2.0.0p2.tar.gz
/usr/portage/distfiles/torque-1.2.0p5-jobnanny.patch
vrapenec torque # 

Created an attachment (id=77522) [edit]
torque-2.0.0_p2.ebuild - path fix

Hi.

The problem with EPATCH_SOURCE fixed.
Works for me :)

Please Test and report

OK, now it works.

What about the /usr -> /var change? I'm running torque on a cluster system
where it is easier to have a common (read-only) /usr and a per-node /var.

In fact, '/var/spool/PBS' is the default location. I'm not sure why this was
changed in the first place, but the ebuild itself says "this needs to move to
/var later on". It would be nice to make this change with the version bump.

Finally, it might be nice to have a use flag for a client only (no-server)
build, but that isn't important for this release. Still, it should be easy as
replacing "--enable-server" with "$(use_enable pbsserver server)".

I have tested the latest ebuild posted here, and it works-for-me as is. I can
also confirm it works if I rename the ebuild to p5, and change /usr to /var.

~J

(In reply to comment #14)
> Finally, it might be nice to have a use flag for a client only (no-server)
> build, but that isn't important for this release. Still, it should be easy as
> replacing "--enable-server" with "$(use_enable pbsserver server)".

I agree; we've discussed this in the past. The flag should really be "server"
because that's the uncommon build; you may build 20 times for clients and once
for a server.

Well... the USE flag "server" is already out there and so is 2.0.0P7 ;)

*** Bug 120833 has been marked as a duplicate of this bug. ***

Created an attachment (id=78454) [edit]
destdir-fixes.patch adapted for 2.0.0p5 and works fine with p7

Created an attachment (id=78455) [edit]
respect-destdir adapted for 2.0.0p7

Created an attachment (id=78457) [edit]
respect-ldflags.patch adapted for 2.0.0p5 and works fine with p7

Created an attachment (id=78458) [edit]
destdir-fixes.patch adapted for 2.0.0p5 and works fine with p7

Created an attachment (id=78459) [edit]
makedepend.patch adapted for 2.0.0p5 and works fine with p7

Created an attachment (id=78461) [edit]
torque-2.0.0_p7.ebuild

(From update of attachment 78461 [edit])
Ebuild for torque-2.0.0p7 based on torque-2.0.0p5 ebuild (which was most
probably based on torque-2.0.0p5 ebuild)

Some notes:
$(use_enable pbsserver server) is implemented
I have doubts about the following einfo at qmerge:
 * Building spool directory under
/var/tmp/portage/torque-2.0.0_p7/image//var/spool/PBS/

This ebuild is a mofication of one made by a friend for p5 which was most
probably based on the one for p2.

Just to follow up on the /usr -> /var change. The init scripts in
openpbs-common will also have to be updated.

Is that einfo line just misleading? Are these directories created at merge
time, not at package build time?

And, I fear I've introduced a bug. It should be $(useenable server), not
$(useenable pbsserver server). (I was unaware of the existance of the server
use flag, so I envisioned a local use flag named pbsserver.)

Other than that, the new ebuild and patches work for me for p7.

Um... $(use_enable server)
But you knew that already.

Created an attachment (id=78514) [edit]
respect-destdir - Revised to correct tclIndex bug.

Thought this was fixed, but the destdir fixes for the tcl guis seems to not be
working. I get errors caused by paths to
/var/tmp/portage/torque-2.0.0_p7/image/ remaining in the tclIndex files.
This modified respect-destdir uses a similar fix to bug 101326. See bug 101326,
comment 20 for details.

[...]
make[1]: Leaving directory
`/var/tmp/portage/torque-2.0.0_p7/work/torque-2.0.0p7/doc'
>>> Source compiled.
torque-2.0.0p7
>>> Test phase [not enabled]: sys-cluster/torque-2.0.0_p7
torque-2.0.0p7

>>> Install torque-2.0.0_p7 into /var/tmp/portage/torque-2.0.0_p7/image/ category sys-cluster
 * Building spool directory under
/var/tmp/portage/torque-2.0.0_p7/image//var/spool/PBS/
 * Running make install
Making install in src
make[1]: Entering directory
`/var/tmp/portage/torque-2.0.0_p7/work/torque-2.0.0p7/src'
Making install in resmom
make[2]: Entering directory
`/var/tmp/portage/torque-2.0.0_p7/work/torque-2.0.0p7/src/resmom'
/bin/sh ../../buildutils/pbs_mkdirs mom
mkdir: cannot create directory
`/var/tmp/portage/torque-2.0.0_p7/image//var/spool/PBS/': File exists

[...]
#
for f in ./*.tcl ./*.tk; do \
    ../../.././buildutils/install-sh -c -m 644 $f
/var/tmp/portage/torque-2.0.0_p7/image//usr/lib/pbs/xpbsmon; \
done
#
# install xpbsmon changing the location of pbs_tclsh and libdir
#
../../.././buildutils/install-sh -c -m 755 xpbsmon
/var/tmp/portage/torque-2.0.0_p7/image//usr/bin/xpbsmon
chmod 755 /var/tmp/portage/torque-2.0.0_p7/image//usr/bin/xpbsmon 2> /dev/null
#
../../.././buildutils/install-sh -c -m 755 buildindex
/var/tmp/portage/torque-2.0.0_p7/image//usr/lib/pbs/xpbsmon
../../.././buildutils/install-sh -c -m 644 xpbsmonrc
/var/tmp/portage/torque-2.0.0_p7/image//usr/lib/pbs/xpbsmon
#
cd /var/tmp/portage/torque-2.0.0_p7/image//usr/lib/pbs/xpbsmon && ./buildindex
. /usr/lib/pbs/xpbsmon && chmod 644 tclIndex
couldn't open "tclIndex": no such file or directory
    while executing
"open tclIndex"
    invoked from within
"if { $doit } {
  puts -nonewline "Running auto_mkindex..."
  auto_mkindex $tclIndex_dir $libdir/*.{tk,tcl}

  set f [open tclIndex]
  while {[gets $f ..."
    (file "./buildindex" line 119)
Running auto_mkindex...make[3]: *** [install] Error 1
make[3]: Leaving directory
`/var/tmp/portage/torque-2.0.0_p7/work/torque-2.0.0p7/src/tools/xpbsmon'
make[2]: *** [install] Error 2
make[2]: Leaving directory
`/var/tmp/portage/torque-2.0.0_p7/work/torque-2.0.0p7/src/tools'
make[1]: *** [install] Error 2
make[1]: Leaving directory
`/var/tmp/portage/torque-2.0.0_p7/work/torque-2.0.0p7/src'
make: *** [install] Error 2

!!! ERROR: sys-cluster/torque-2.0.0_p7 failed.
Call stack:
  ebuild.sh, line 1894:   Called dyn_install
  ebuild.sh, line 1037:   Called src_install

Created an attachment (id=79344) [edit]
Fix for the tclIndex problem without sandbox access violations

I get access violations from the latest destdir-fixes.patch that fixes the
tclIndex problem. This ebuild along with the previous version of
torque-2.0.0_p7-destdir-fixes.patch works fine for me, as do xpbs and xpbsmon.
I just used sed to remove ${D} from all the tclIndex files in ${D} at the end
of src_install.

Created an attachment (id=79374) [edit]
A version of /etc/init.d/pbs that's aware of torque moving from /usr/ to /var/

So I spent a large amount of time figuring out why pbsnodes told me I had no
node list only to discover torque had moved. Having the pbs init script look in
/usr threw me for a long time and it took strace telling me what file
pbs_server was opening to figure it out. Anyway, here's an updated version of
the pbs init script that's aware of torque's multiple locations.
openpbs-common-1.1.1 will follow...

Created an attachment (id=79375) [edit]
openpbs-common-1.1.1.ebuild, with a torque location aware init script

You'll also need to make torque-2.0.0_p7 depend on this instead of
openpbs-common.1.1.0. Also, I think it should be openpbs-common-1.1.0-r1, but
portage complains about names. Should openpbs-common have been openpbs_common?

Any progress on this in the past month?  What all has changed now wrt
installation?? (ie, will i have to protect my /usr/spool/PBS dir and/or move it
to /var now?  or is all fine and dandy?)

OK update -- attachment 78514 [edit] (torque-2.0.0_p7-respect-destdir.patch) doesn't
work for me.  The previous one (attachment 78455 [edit]) works fine.

Also, attachment 79374 [edit] (torque_2.0.0_p7.ebuild) seems to work just fine, while
attachment 78461 [edit] doesn't work for me (sandbox access violations as previously
stated).

Could someone obsolete those two attachments (78514, 78461) to avoid confusing
any testers..?

Created an attachment (id=81613) [edit]
fix to remove errors when no pbs_sched was installed

If 'pbsserver' use flag isn't specified, pbs_sched isn't built, and the
previously submitted attachment 79374 [edit] used a global 'which' to try and find its
location.  When that 'which' fails it makes a nasty error message on startup. 
This just moves the 'which' call, etc. to after the Use-PBS-Server check.

BTW -- using 'openpbs-common-1.1.0-r1' works fine for me, not sure why it
wouldn't for you...?

Found another problem though -- this one was in the 1.x ebuilds too..  When
upgrading or re-merging, all the empty dirs in /*/spool/PBS/ are removed, but
they're still needed by pbs_mom, pbs_server, pbs_sched, etc even though they're
empty.  Any suggestions?  Just use .keep files?

(In reply to comment #35)
> empty.  Any suggestions?  Just use .keep files?

The .keep files are provided by calls to keepdir().

Created an attachment (id=81621) [edit]
update pbs-env.d to CONFIG_PROTECT var/spool/PBS as well

I knew there was a way to fix this without .keep files.. CONFIG_PROTECT was set
in openpbs-common to use /usr/spool/PBS, so i added /var/spool/PBS to this one
so it will protect both.

openpbs-common-1.1.1.ebuild should be edited to use this file instead of
pbs-env.d

(In reply to comment #15)
> (In reply to comment #14)
> > Finally, it might be nice to have a use flag for a client only (no-server)
> > build, but that isn't important for this release. Still, it should be easy as
> > replacing "--enable-server" with "$(use_enable pbsserver server)".
> 
> I agree; we've discussed this in the past. The flag should really be "server"
> because that's the uncommon build; you may build 20 times for clients and once
> for a server.
> 

What about adding USE flags to allow users to (not) install client or mom
stuff?  It might not be the most common method, but if you've got a bunch of
headless systems running mom you don't really need the client utils either..
and vice-versa, if your client systems aren't going to work as processor nodes
you don't need mom..

...would it be better to split the ebuild into three (pbs-server, pbs-mom,
pbs-clients) instead of using USE flags for this?  Or is this just
over-engineering everything?

Personally I would find suggestion per comment #38 the best - to have 3
separate packages, I think I like it more then having some cryptic "server" USE
flag. But, most importantly, I don't care spending extra few CPU cycles to
compile and install everything and everywhere if that would speedup getting any
ebuild for torque-2 into portage tree. ;)

oop, another minor fix..  

torque-2.0.0_p7.ebuild (attachment 79344 [edit]) has 'server' in IUSE but 'pbsserver'
in src_configure -- we should be using one or the other.. 

@@ -53,3 +53,3 @@
                $(use_enable X gui) \
-               $(use_enable pbsserver server) \
+               $(use_enable server) \
                $(use_with tcltk tcl) \

I got a couple of questions about the torque .ebuild:

1- why is sys-cluster/openpbs-common a PDEPEND instead of a part of
DEPEND-COMMON?

2-does torque always RDEPEND on net-misc/openssh even if USE=-ssh ??

In comment #41 I guess you wanted to talk about 'scp' USE instead of 'ssh'
flag, right? ;-) I cannot answer you my point would be that the ebuild should
either in theory check that either rshd/rsh/rcp or sshd/ssh/scp are installed.
It should either require lets say app-crypt/heimdal (if bug #125443 is resolved
so that torque would either look for krsh, etc. or for the standard names like
rsh, etc.), app-crypt/mit-krb5, net-misc/netkit-rsh ... maybe other packages
provide rshd/rsh/rcp/rlogin as well?

Oh yeah, this built and ran for me on both x86 and amd64, with USE=server and
without.

I put an experimental torque-2.0.0_p8 ebuild and patches in the Gentoo
Scientific overlay: http://gentooscience.org
I tried to gather information in this bug and did quick obvious changes. The
ebuild obviously needs more work.
Please report tests, suggestions and patches here.

(In reply to comment #44)
> I put an experimental torque-2.0.0_p8 ebuild and patches in the Gentoo
> Scientific overlay: http://gentooscience.org

You'll need to add the overlay and patches to sys-cluster/openssh-common as
found above (for openssh-common-1.1.1) and make the torque ebuild require that
version.

I don't know if there's much point in just duplicating all the .patch files
when their internals are the same, but i guess that's more of a design issue..

What other work do you think this needs?

Should we file a separate bug for the openpbs-common updates?  Or is it still
too early for that?

I did some slight updates in the overlay:
- added openpbs-common-1.1.1
- added a pic USE flag (necessary when used with openmpi)
- removed the X flag. If you want the gui, use USE=tcltk, which needs tclx
  it looks like the gui is only tk based. tcl use is weird in this package
- if scp is not enabled, the ebuild depends on netkit-rsh

..is there any way to properly set or define --set-default-server= in this
ebuild?  (On _p7 at least) if this isn't set all the clients default to
connecting to a server with the local hostname, which is pretty useless if
you're installing this with USE=-server

I can't think of any way to do it that wouldn't look like a hack though...

(In reply to comment #47)
> - added a pic USE flag (necessary when used with openmpi)

Shouldn't be a USE flag, should be unconditional, assuming this only controls
whether libpbs.a is compiled as PIC.

(In reply to comment #49)
> Shouldn't be a USE flag, should be unconditional, assuming this only controls
> whether libpbs.a is compiled as PIC.

Is it safe to always compile this with -fPIC?  (i don't have the resources/time
to test right now)..  

If it isn't safe in the general case, would it be more conformative to change
the useflag from 'pic' to 'openmpi' (and OR this with any other package-name
use flags that would require -fPIC)?

(In reply to comment #50)
> Is it safe to always compile this with -fPIC?  (i don't have the resources/time
> to test right now).. 

If it works in one case, it should work in any.

Ebuild updated to reflect these last comments:
* reverted to force -fPIC on all arch
* PBS_SERVER_NAME=<myserver> emerge torque should do the trick to set the 
PBS server hostname

As I understood after reading some posts at torque dev mailing lists,
libtoolization is planned if not in cvs already. Considering the mess the
autotools are in this current version, it is safer to add append-flag -fPIC and
stick with static pic libs only and wait for the next version for shared libs.
It worked on my amd64 (and confirmed by the same upstream post).

(In reply to comment #52)
> As I understood after reading some posts at torque dev mailing lists,
> libtoolization is planned if not in cvs already. Considering the mess the
> autotools are in this current version, it is safer to add append-flag -fPIC and
> stick with static pic libs only and wait for the next version for shared libs.

I will be very annoyed if that ever ends up in portage.

Hey, why did "use_enable X gui" get changed?  tclx/tcktk isn't required for
xpbs and xpbsmon to work....

(In reply to comment #54)
> Hey, why did "use_enable X gui" get changed?  tclx/tcktk isn't required for
> xpbs and xpbsmon to work....

I have tested torque with/without tcl and tk, and with tcl/tk installed but
with use flag tcltk disabled: I came to the conclusion there exists only one
gui, based on tcl/tk. Other tests failed.

Alsno note the ebuild on the overlay has been updated for quite a while now to
have only libpbs.a built with -fPIC (see comment #53).

torque-2.1.0p0 is out. It may need extra work, but I've comited an ebuild at
http://gentooscience.org. Only one patch is needed so far, this new version
includes a much proper autotools system.

soo...  any chance that one of these versions are going to get into portage
sometime soon?

Maybe, I'm hoping to find some money to buy enough memory to set up a small
test cluster in vmware-server.

(In reply to comment #58)
> Maybe, I'm hoping to find some money to buy enough memory to set up a small
> test cluster in vmware-server.
> 

Is RAM all you are missing, really? Can't be that expensive to get. Hell,
Torque is such a b**ch to get working correctly I'm sure people would be happy
to help you out with your RAM dilemma ;)

For about $220 I could get another 2G (
http://www.monarchcomputer.com/Merchant2/merchant.mv?Screen=PROD&Store_Code=M&Product_Code=140270&Category_Code=REG_DDR
). It will take me at least a few months to save that up.

(In reply to comment #60)
> For about $220 I could get another 2G (

Okay...how about now :)

Still wondering if/when this is ever going to make it to portage...

Getting the latest stuff into the science overlay and testing it would help to
speed up that process.

Finally in the tree. Thanks for your work on this, and for dealing with the
delay.

One other note, you may still need the science overlay for tclx 8.4 since 8.3.5
is the latest in the tree and it doesn't work with gcc4.

woohoo!  fantastic!

Regarding tclx/gcc-4 -- i had an issue with it on amd64 as well with
gcc-3.x/glibc-2.3.. I just changed the 'tk' dependency to ( dev-lang/tcl
dev-lang/tk ) and everything still works fine.  The ebuild doesn't contain a
$(use_with tk tclx) so it doesn't actually need tclx..  

(In reply to comment #66)
> woohoo!  fantastic!
> 
> Regarding tclx/gcc-4 -- i had an issue with it on amd64 as well with
> gcc-3.x/glibc-2.3.. I just changed the 'tk' dependency to ( dev-lang/tcl
> dev-lang/tk ) and everything still works fine.  The ebuild doesn't contain a
> $(use_with tk tclx) so it doesn't actually need tclx..  

No, but the gui does require tclx ... and after looking into it a bit, tclx 8.4
doesn't provided needed stuff for the gui so you will require gcc 3.x if you
want it.

The beginnings of a patch are at
http://www.clusterresources.com/pipermail/torqueusers/2006-March/003306.html
but it's screwed up -- patches configure directly instead of configure.ac and
buildutils/tcl.m4.

Huh?  The gui (xpbs,xpbsmon) works fine with just tcl and tk.  I think we've
had this conversation before.  You can use tclx for the gui but its not
necessary (at least on my x86 and amd64 servers).

Note, pbs_wish and pbs_tclsh im not sure of though, as i don't use those, but
from my limited searching in the package source they don't look to be dependent
on '--with-gui'.. if they need tclx then i'm entirely wrong.

According to their configure script, it shouldn't be built/installed if tclx
isn't found.

In configure.ac the only dep-relationship with gui that i see has to do with
'TK' being '1'.  Indeed, by default if TK is found (=1) and gui isn't
explicitly disabled by the user, then the gui is built.  If TCL is not found
(=0) it does seem to skip checking for TK, but there is no such dep. with TCLX
(TCLX=0 means no check for TKX, but there's nothing relating TKX to an
enabled/disabled gui)

configure.ac summary:
  line 979(et.al) checks for TCL
  line 1002(et.al) checks for TCLX if TCL=1
  line 1020(et.al) checks for TK if TCL=1
  line 1043(et.al) checks for TKX if TK=1 and TCLX=1
  line 1067(et.al) checks for GUI if TK=1

..which explains why everything builds and runs for me even though I have no
tclx or tkx on my systems :)

Maybe I misunderstood the meaning of the *X variables, I don't have the time to
go digging again... thanks for looking into it.

BTW, if I remember right I had to use gcc-3.3.6 to ciompile this. gcc-3.4.6
broke in the same way as 4.1.1. Sorry for not posting more details, I am
writing it from top of my head after few days. :(

I've been compiling everything with 4.1.1-r1 and it works great. Maybe 3.4.6 is
broke..

I've had no problems with either of 3.4.6 or 4.1.1, on both x86 and amd64 (ok
im not using 4.1.1 with amd64 yet)

Sorry for misleading note, my comment #73 was about the necessity to compile
tclx using other gcc than 4.1.1. I have managed to use gcc-3.4.6 on one host
now. The problem was:

make[1]: Entering directory
`/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix'
cc -pipe -Wall -c   -march=pentium4 -mmmx -msse -msse2 -O3 -fomit-frame-pointer
-funroll-loops -pipe  -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1
-DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1
-DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1
-DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1
-DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1
-DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1
-DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1
-DPEEK_XCLOSEIM=1 -DHAVE_SYS_IOCTL_H=1  -DSTDC_HEADERS=1 -Dclock_t=long
-DRETSIGTYPE=void -DTIMES_RETS_STATUS=1 
-I/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/generic
-I/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix
-I/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix
-I/var/tmp/portage/tclx-8.3.5/work/tcl8.4.6/generic
-I/var/tmp/portage/tclx-8.3.5/work/tcl8.4.6/unix
/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix/tclXAppInit.c
cc -pipe -Wall -c -o tclXbsearch..o   -march=pentium4 -mmmx -msse -msse2 -O3
-fomit-frame-pointer -funroll-loops -pipe  -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1
-DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1
-DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1
-DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1
-DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1
-DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1
-DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1
-DPEEK_XCLOSEIM=1 -DHAVE_SYS_IOCTL_H=1  -DSTDC_HEADERS=1 -Dclock_t=long
-DRETSIGTYPE=void -DTIMES_RETS_STATUS=1 
-I/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/generic
-I/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix
-I/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix
-I/var/tmp/portage/tclx-8.3.5/work/tcl8.4.6/generic
-I/var/tmp/portage/tclx-8.3.5/work/tcl8.4.6/unix -fpic \
           
/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/generic/tclXbsearch.c
In file included from /usr/include/sys/times.h:29,
                 from
/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix/tclXunixPort.h:32,
                 from
/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/generic/tclExtdInt.h:27,
                 from
/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/generic/tclXbsearch.c:19:
/usr/include/time.h:61: error: two or more data types in declaration specifiers
/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/generic/tclXbsearch.c: In
function 'TclProcKeyCompare':
/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/generic/tclXbsearch.c:115:
warning: passing argument 2 of 'Tcl_Merge' from incompatible pointer type
make[1]: *** [tclXbsearch..o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/tclx-8.3.5/work/tclx8.3.5/tcl/unix'
make: *** [TCLX] Error 2

!!! ERROR: dev-tcltk/tclx-8.3.5 failed.
Call stack:
  ebuild.sh, line 1546:   Called dyn_compile
  ebuild.sh, line 937:   Called src_compile
  tclx-8.3.5.ebuild, line 65:   Called die