root@noname $ emerge --info !!! Relying on the shell to locate gcc, this may break !!! DISTCC, installing gcc-config and setting your current gcc !!! profile will fix this Portage 2.0.53_rc7 (!/usr/local/portage/portage-alt-overlay/profiles/default-bsd/obsd/3.8, gcc-3.3.5, unavailable, 3.8 i386) ================================================================= System uname: 3.8 i386 Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) Gentoo/obsd Base System version 0.1 dev-lang/python: 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: [Not Present] sys-devel/libtool: 1.5.20-r1 virtual/os-headers: [Not Present] ACCEPT_KEYWORDS="x86 ~x86 ~x86-fbsd ~x86-obsd" AUTOCLEAN="yes" CBUILD="i386-gentoo-openbsd3.8" CFLAGS="-mcpu=i386 -O2 -pipe" CHOST="i386-gentoo-openbsd3.8" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=i386 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/portage-alt-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86-obsd userland_BSD kernel_OpenBSD elibc_OpenBSD" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS I'am using the lastest portage overlay from http://gentoo.osuosl.org/experimental/snapshots/portage-alt-overlay-latest.tar.bz2 *************************** root@noname $ emerge metadata skipping sync >>> Updating Portage cache: 100% * An update to portage is available. It is _highly_ recommended * that you update portage now, before any other packages are updated. * Please do so and then update ALL of your configuration files. root@noname $ emerge portage Calculating dependencies ...done! >>> emerge (1 of 3) app-misc/pax-utils-0.1.13 to / chflags: invalid flag: nosunlnk >>> md5 src_uri ;-) pax-utils-0.1.13.tar.bz2 >>> Unpacking source... >>> Unpacking pax-utils-0.1.13.tar.bz2 to /var/tmp/portage/pax-utils-0.1.13/work >>> Source unpacked. gcc -mcpu=i386 -O2 -pipe -D_GNU_SOURCE -DVERSION="0.1.13" -o scanelf.o -c scanelf.c scanelf.c: In function `scanelf_file_rpath': scanelf.c:642: warning: overflow in implicit constant conversion scanelf.c:755:2: warning: #warning Cache support not implemented for your target scanelf.c:1483:2: warning: #warning Cache config support not implemented for your target scanelf.c: In function `load_ld_cache_config': scanelf.c:1487: warning: control reaches end of non-void function scanelf.c: In function `parseargs': scanelf.c:1830: error: `__PAX_UTILS_DEFAULT_LD_CACHE_CONFIG' undeclared (first use in this function) scanelf.c:1830: error: (Each undeclared identifier is reported only once scanelf.c:1830: error: for each function it appears in.) gmake: *** [scanelf.o] Error 1 !!! ERROR: app-misc/pax-utils-0.1.13 failed. !!! Function src_compile, Line 26, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message.
fixed in overlay.
I'm sorry. Thats not a proper fix. A proper fix would be to attach a patch here and let me review it. If it don't suck I'll add it to cvs and it will be in the next release of the pax-utils.
Created attachment 87434 [details, diff] here you have this small workaround... You forgot #ifdef for load_ld_cache_config() if __PAX_UTILS_DEFAULT_LD_CACHE_CONFIG is undefined. FreeBSD and DragonFlyBSD have /var/run/ld-elf.so.hints, OpenBSD and probably NetBSD have /var/run/ld.so.hints. Could you handle with this?
(In reply to comment #3) > FreeBSD and DragonFlyBSD have /var/run/ld-elf.so.hints, OpenBSD and probably > NetBSD have /var/run/ld.so.hints. NetBSD ELF doesn't use a hints file, you can simply read only /etc/ld.so.conf.
Thanks a lot it works now.
(In reply to comment #4) > NetBSD ELF doesn't use a hints file, you can simply read only /etc/ld.so.conf. Harald, care to take a stab at patching it to support such?
The code is there. It's the same format as for glibc, where ld.so.conf gets checked already. It should just be a matter of checking for __NetBSD__ too. I'll make sure it actually works with that as soon as I can, and try to come up with a patch if it doesn't.
Created attachment 87530 [details, diff] pax-utils patch for netbsd It really was as simple as adding a few checks for __NetBSD__.
(In reply to comment #8) > Created an attachment (id=87530) [edit] > pax-utils patch for netbsd > > It really was as simple as adding a few checks for __NetBSD__. Is there a reason for this hunk? +#ifndef __NetBSD__ #warning Cache support not implemented for your target +#endif
And scanelf -lLn works? It's output is for sure not the same as -ln ?
> Is there a reason for this hunk? NetBSD ELF, as I said earlier, only uses ld.so.conf. There is no cache, there is no point warning about it. > And scanelf -lLn works? It's output is for sure not the same as -ln ? See above.
So does -Ln work or not? If it does not then there is little point in patching the code from my POV. Flameyes please review these *BSD hacks. I think you know what we are after as the end result with the -Ln and friends (regardless if the arch supports a cache or not).
> So does -Ln work or not? If it does not then there is little point in patching > the code from my POV. No, -Ln without -l doesn't work. If there is no cache, and you tell scanelf to search only the cache, what is supposed to happen?
i2 ~ # scanelf -Ln /bin/ls TYPE NEEDED FILE ET_EXEC /lib/librt.so.1,/lib/libc.so.6.1 /bin/ls vs. i2 ~ # scanelf -n /bin/ls TYPE NEEDED FILE ET_EXEC librt.so.1,libc.so.6.1 /bin/ls The -L option is supposed todo it's best to resolve the path that would be used by the dynamic linker. This option is planned for later revdep rebuilding optons via portage by simply looking at the DT_NEEDED without having to rely on any form of ldd. It should be able to differentiate between 32 & 64bit code. In the cases where a given library exists in more than one path the first fitting match is returned.
Ah, thanks for the explanation. I'll see what I can do to make sure that works properly.
Created attachment 88071 [details, diff] pax-utils patch for netbsd This should do it. It's not complete, but a complete and safe solution is probably impossible, and on Gentoo/NetBSD, it should only fail if you intentionally do something stupid.
This was commited to CVS a while ago.. bsd@ you can close this..
Closing on behalf of the BSD team then. File a new bug for new bsd compile failures. Thanks for reporting.
