Bugzilla Bug 179408

Please mark 0.30-r2 stable, so we can get rid of the old crap ...

From the man page:

       diet  tries  to be smart for cross compiling.  If the first argument is
       not gcc but sparc-linux-gcc, diet will guess that  you  want  to  cross
       compile   for   sparc  and  use  bin-sparc/dietlibc.a  instead  of  the
       dietlibc.a for your default architecture.

This means that for hppa, diet incorrectly tries to find library archives in
/usr/diet/lib-hppa2.0 because of hppa2.0-unknown-linux-gnu, instead of
/usr/diet/parisc where the files really are. This means that it does build
sys-libs/libvserver, but doesn't properly build app-shells/shish with USE=diet.

Other than that, stable for HPPA.

This is  amore or less known issues, we aready have a patch that renames ppc to
powerpc for similar reason ... but eventually this has to be fixed upstream..
will try to contact fefe about this ..

alpha stable

won't work on ppc:

>>> Compiling source in /var/tmp/portage/dev-libs/dietlibc-0.30/work/dietlibc-0.30 ...
Makefile:66: *** unknown architecture, please fix Makefile.  Stop.

!!! ERROR: dev-libs/dietlibc-0.30 failed.

You have a patch for this?

fortunately the new epatch breaks a lot of patches that are not named like the
author of epatch wishes them to be named *sigh*

so i assume 150_ppc_rename-powerpc.patch has not even got applied in your
build, right?

hm.. although it applies fine here .. hm .. maybe i only got that impression
because of the apache ebuilds ;)

(In reply to comment #5)
> fortunately the new epatch breaks a lot of patches that are not named like the
> author of epatch wishes them to be named *sigh*
> 
> so i assume 150_ppc_rename-powerpc.patch has not even got applied in your
> build, right?
> 

>>> Unpacking dietlibc-0.30-patches-r0.tar.bz2 to /var/tmp/portage/dev-libs/dietlibc-0.30/work
 * Applying 00_all_custom-cflags.patch ...                                [ ok
]
 * Applying 01_all_nostrip.patch ...                                      [ ok
]
 * Applying 02_all_want-stackgap.patch ...                                [ ok
]
 * Applying 03_all_ppc-rename.patch ...                                   [ ok
]
 * Applying 04_all_prefix.patch ...                                       [ ok
]
 * Applying 20_all_dirent-prototype.patch ...                             [ ok
]
 * Applying 21_all_nice.patch ...                                         [ ok
]
 * Applying 40_sparc64_Makefile.patch ...                                 [ ok
]
 * Applying 42_arm_waitpid.patch ...                                      [ ok
]
 * Applying 43_ia64_no-fno-omit-frame-pointer.patch ...                   [ ok
]
 * Applying 45_parisc_iitlbp.patch ...                                    [ ok
]
>>> Source unpacked.

Guess it doesn't

Not too suprising since that patch is not in the tarball
dietlibc-0.30-patches-r0.tar.bz2

ah, this bug is about dietlibc-0.30-r2 not r0 :)

on ppc64 (64ul):

gcc -m64 -I. -isystem include -O2 -pipe -mcpu=970 -mtune=970 -mabi=altivec
-fomit-frame-pointer -c libregex/rx.c -o bin-powerpc64/rx.o -D__dietlibc__
make: *** No rule to make target `bin-powerpc64/__longjmp.o', needed by
`bin-powerpc64/dietlibc.a'.  Stop.


Do you want emerge --info and build.log?

Created an attachment (id=121462) [edit]
fixed Makefile.add in powerpc/

Created an attachment (id=121464) [edit]
fixed Makefile.add in powerpc64/

Okay, fixed the patches. Now it compiles cleanly on ppc64 (64ul).

the powerpc/Makefile.add had the wrong VPATH because of the changes in the
dirs.

José Costa: Good work. Are those patches your work? Have they been sent
upstream? I'll try those out once I get some spare time and include them in
portage.

(In reply to comment #14)
> José Costa: Good work. Are those patches your work? Have they been sent
> upstream? I'll try those out once I get some spare time and include them in
> portage.
> 

No, the patches are from Hollow.

all ppc/ppc64 bugs we could find have been fixed in 0.31_pre20070611, won't
backport it to 0.30, therefore removing ppc teams...

(In reply to comment #1)
> This means that for hppa, diet incorrectly tries to find library archives in
> /usr/diet/lib-hppa2.0 because of hppa2.0-unknown-linux-gnu, instead of
> /usr/diet/parisc where the files really are. This means that it does build
> sys-libs/libvserver, but doesn't properly build app-shells/shish with USE=diet.
> Other than that, stable for HPPA.

I still see the same behavior trying to emerge
sys-cluster/util-vserver-0.30.215 - it fails with dev-libs/dietlibc-0.30-r2 and
-0.31_pre20070612 too:

[.....]
diet -Os hppa2.0-unknown-linux-gnu-gcc -O2 -pipe -march=2.0 -std=c99 -Wall
-pedantic -W -funit-at-a-time -o tests/getctx tests/getctx.o  lib/libvserver.a
-lcompat
hppa2.0-unknown-linux-gnu-gcc: /usr/diet/lib-hppa2.0/start.o: No such file or
directory
hppa2.0-unknown-linux-gnu-gcc: /usr/diet/lib-hppa2.0/libc.a: No such file or
directory
[.....]

AFAIK, this isn't RESOLVED neither FIXED on hppa.

Just to clarify:
 $ diet gcc <whatever>
will use the correct path (/usr/diet/lib-parisc)
 $ diet hppa2.0-unknown-linux-gnu-gcc <whatever>
will try to use a wrong path derived from the CHOST embedded in gcc's command
(/usr/diet/lib-hppa2.0).

The problem arise from the fact that hppa2.0-unknown-linux-gnu is the default
CHOST on Gentoo/hppa2.0 so it'll be probably used by any crosscompile-aware
ebuild/Makefile/whatever.
Probably a renaming patch like the one for ppc would be the way to go.