Hello! I would suggest, we should filter the ldflag "-Wl,--as-needed" I know, that there are using some people this. I can reproduce this error on all of my gentoo pcs. So it should be filtered. If the flag is enabled, we get this error: gcc -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -fomit-frame-pointer -m3dnow -march=k6-3 -mfpmath=387 -mmmx -O3 -pipe -I../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c -o connection.o connection.c ../libtool --mode=link gcc -Wl,--as-needed -o innfeed article.o buffer.o config_l.o config_y.o endpoint.o host.o innlistener.o main.o misc.o tape.o version.o connection.o /var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/storage/libstorage.la /var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/history/libinnhist.la /var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/lib/libinn.la mkdir .libs gcc -Wl,--as-needed -o .libs/innfeed article.o buffer.o config_l.o config_y.o endpoint.o host.o innlistener.o main.o misc.o tape.o version.o connection.o /var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/history/.libs/libinnhist.so /var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/storage/.libs/libstorage.so /var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/lib/.libs/libinn.so -Wl,--rpath -Wl,/usr/lib/news/lib /var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/storage/.libs/libstorage.so: undefined reference to `HISlookup' collect2: ld returned 1 exit status make[1]: *** [innfeed] Fehler 1 make[1]: Leaving directory `/var/tmp/portage/net-nntp/inn-2.4.3/work/inn-2.4.3/innfeed' make: *** [all-innfeed] Fehler 2 !!! ERROR: net-nntp/inn-2.4.3 failed. Call stack: ebuild.sh, line 1629: Called dyn_compile ebuild.sh, line 975: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile inn-2.4.3.ebuild, line 84: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/net-nntp/inn-2.4.3/temp/build.log'.
Created attachment 122689 [details, diff] inn-2.4.3-r1.patch inn-2.4.3-r1.patch patch against inn-2.4.3.ebuild
Thanks, Conrad! Fixed in CVS.
This is _not_ a fix so this bug is not resolved. Reopening.
The problem boils down to a circular dependency. INN creates two libs, libinnhist and libstorage. libinnhist depends on libstorage for a bunch of symbols, so libstorage is built first, and libinnhist is linked with it. However, libstorage never gets relinked against libinnhist, so when the build gets around to linking the innfeed executable, it hits the undefined 'HISlookup' symbol in libstorage and quits. I have no idea if there's some nice, elegant way to deal with a case like this.
*** Bug 248145 has been marked as a duplicate of this bug. ***
So no solution is better than workaround? It's 2009 actually and many many other pkgs have been workarounded that way.
Such "workarounds" are broken by design. You can either learn how to work it around correctly (but that doesn't close the bug) or to fix it properly. Or finally you could learn to ask nicely, but that's probably too hard.
Open for 2 and half year, adding treecleaner@
*** Bug 281721 has been marked as a duplicate of this bug. ***
Hmm - seems a bit odd to not have inn in portage? Is there some new standard NNTP server out there? If we're just looking for a dev to ask nicely for advice on properly working around the as-needed issue and commit the build, I'm sure some could be found. I'm not an inn expert, so I'd hesitate to be the first to volunteer, but I don't mind just taking care of an as-needed patch if not much work is necessary.
Wouldn't adding no-as-needed from flag-o-matic.eclass be the proper workaround here?
This is getting ridiculous. We now have a package.mask entry that lists the wrong masking reason and a pending removal for the wrong reason (--as-needed compliance isn't mandatory AFAIK). This package does need all kinds of attention, but this is the wrong kind. I'm working on 2.5.1.
2.5.0 is in the tree so this bug is fixed.
