Bugzilla Bug 184668

Hiya, just a quick note to say wireshark appears to fail with --as-needed set:

i686-pc-linux-gnu-gcc -DINET6 "-D_U_=__attribute__((unused))" -mtune=prescott
-march=prescott -O -fomit-frame-pointer -pipe -Wall -W
-Wdeclaration-after-statement -Wendif-labels -Wpointer-arith -Wno-pointer-sign
-I/usr/local/include -DPNG_NO_MMX_CODE -pthread -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libpng12 -DNETSNMP_ENABLE_IPV6
-mtune=prescott -march=prescott -O2 -pipe -Ulinux -Dlinux=linux -I.
-I/usr/include -o .libs/dftest dftest.o util.o .libs/dftestS.o
-Wl,--export-dynamic -Wl,-rpath -Wl,/usr/lib -DINET6
"-D_U_=__attribute__((unused))" -mtune=prescott -march=prescott -O
-fomit-frame-pointer -pipe -Wall -W -Wdeclaration-after-statement
-Wendif-labels -Wpointer-arith -Wno-pointer-sign -I/usr/local/include
-DPNG_NO_MMX_CODE -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2
-I/usr/include/libpng12 -DNETSNMP_ENABLE_IPV6 -mtune=prescott -march=prescott
-O2 -pipe -Ulinux -Dlinux=linux -I. -I/usr/include -Wl,--as-needed 
-L/usr/local/lib wiretap/.libs/libwiretap.so epan/.libs/libwireshark.so
-L/usr/lib /usr/lib/libnetsnmp.so -lwrap -lcrypto /usr/lib/libpcre.so
/usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so -lm -lpcap -lkrb5 -lk5crypto
-lcom_err -lresolv -ldl /usr/lib/libgnutls.so /usr/lib/libtasn1.so
/usr/lib/libgcrypt.so /usr/lib/libgpg-error.so -lz
epan/.libs/libwireshark.so: undefined reference to `mpa_samples'
epan/.libs/libwireshark.so: undefined reference to `mpa_versions'
epan/.libs/libwireshark.so: undefined reference to `mpa_padding'
epan/.libs/libwireshark.so: undefined reference to
`wtap_pcap_encap_to_wtap_encap'
epan/.libs/libwireshark.so: undefined reference to `mpa_frequencies'
epan/.libs/libwireshark.so: undefined reference to `mpa_layers'
epan/.libs/libwireshark.so: undefined reference to `mpa_bitrates'
collect2: ld returned 1 exit status
make[2]: *** [dftest] Error 1
make[2]: Leaving directory
`/var/tmp/portage/net-analyzer/wireshark-0.99.6/work/wireshark-0.99.6'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/net-analyzer/wireshark-0.99.6/work/wireshark-0.99.6'
make: *** [all] Error 2
 * 
 * ERROR: net-analyzer/wireshark-0.99.6 failed.
 * Call stack:
 *   ebuild.sh, line 1642:   Called dyn_compile
 *   ebuild.sh, line 988:   Called qa_call 'src_compile'
 *   ebuild.sh, line 44:   Called src_compile
 *   wireshark-0.99.6.ebuild, line 109:   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-analyzer/wireshark-0.99.6/temp/build.log'.
 * 

Interestingly, the command that caused this was:

MAKEOPTS="-j1" LDFLAGS="" emerge --oneshot wireshark

but somehow --as-needed somehow slipped back in.  It's probably just a library
ordering problem, I don't recall having the problem with wireshark-0.99.5.  If
there's any more information I can provide (like emerge --info), just let me
know...  5:)

Seem to have narrowed this down to krb5-config, which when called with --libs
presents the following:

plasma ~ # krb5-config --libs
-L/usr/lib -Wl,-rpath -Wl,/usr/lib -Wl,--as-needed -lkrb5 -lk5crypto -lcom_err
-lresolv -ldl

That means that even if LDFLAGS="" set wireshark will still fail to build. 
This looks more like a kerberos failure going on somewhere, I just haven't
determined exactly where yet.  I'm reassigning to the kerberos crew for some
help...

So sadly, even without the mit-krb5 issue, it still doesn't compile properly
with --as-needed.  Luckily hanno opened bug 184798 for the original issue,
whilst I'm going to keep this bug running for the mit-krb5 issue...

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

Let's have wireshark in Summary. In other case I've already lost this bug
report once...

Reported upstream.

Created an attachment (id=124422) [details]
wireshark-0.99.6-asneeded.patch

modification to epan/Makefile.am, include ${top_builddir}/wiretap/libwiretap.la
in 
deps and libadd..

Created an attachment (id=124424) [details]
wireshark-0.99.6.ebuild.patch

modifications to ebuild..

needs to be tested by others than me. builds fine here with asneeded.

Created an attachment (id=124426) [details]
correct wireshark-0.99.6.ebuild.patch

meh..

I still think this might be two issues, given that mit-krb5 probably shouldn't
include the --as-needed flag to all underlying compilations, simply because it
was compiled with it?  I'm not sure I'd have marked the other bug as a
duplicate of this one...

patch works, can you commit to portage please?

(In reply to comment #9)
> I still think this might be two issues, given that mit-krb5 probably shouldn't
> include the --as-needed flag to all underlying compilations, simply because it
> was compiled with it?  I'm not sure I'd have marked the other bug as a
> duplicate of this one...
> 

Leaving this bug open for this.

(In reply to comment #10)
> patch works, can you commit to portage please?
> 

Done.

pva, committed it because of multiple requests, poke me if you have better
solution.

Samuli, that's Ok now. The patch should work and additional issues armin76 is a
problem with wireshark-0.99.5 too, which is stable, thus no new problems should
appear.

Leaving this bug for kerberos LDFLAGS problem.

As needed problem is fixed already. Removing blocker of 129413. Updated summary
to reflect state of affairs.

ping :)

I'm not entirely sure what you all want the kerberos team to do with this.  If
anyone has a patch for me, please attach.

i don't have the patch but probably at the end of ebuild, when stripping
symbols for istance, you can strip out some $LDFLAGS

*I* don't want anything, wireshark now builds and I couldn't care less if
kerberos config includes custom ldflags in it's --libs output.

Removing CC.

so close it...

Closing with the comment that if a user has custom LDFLAGS, that's their
business, I'm afraid.

Guys, please.  This bug shouldn't be closed, it's a bug and it's still present.
 Every other program under the sun manages not to include --as-needed in their
pkg-config type output.  If we're closing bugs because of as-needed in LDFLAGS
then there's 19 open sitting in a year and a half old tracker (bug 129413) that
should probably be marked INVALID too.

I understand this bug may not be moving anywhere and I understand drac may not
want to be CCed anymore, which is fine, but please just leave the bug sit
there, don't invent reasons to close it.

Patrizio, the ping spam wasn't particularly helpful, and even less helpful was
your request to close somebody else's bug.  Drac may not have been inclined to
help, but the bug still exists.

What would be more helpful is finding out if someone's contacted upstream about
this?  I have the feeling pva's comment 5 was regarding wireshark and not
mit-krb5.  Could someone from the Kerberos group let me know if this has been
reported upstream yet, and if so, what their bug number is?

Either way, I'm going to re-open this, even if it just sits here.  It hasn't
been fixed to my knowledge, and it's not invalid just because of as-needed...

Well, I have not contacted upstream about it, and I'm not particularly inclined
to.  Mike, if you wish to, please go right ahead.

Created an attachment (id=132681) [details]
krb5-1.5.3-noldflags-config.patch

Well, should you ever decide to contact upstream, here's a patch for it.  It's
a little ugly, but then so is their krb5-config script (as attested by a
comment in the script itself).  I couldn't find a bug tracker, and I'm getting
the general vibe (seeing as you're the only member of the herd) that kerberos
related packages are generally not fun to look after, so I doubt I'll contact
them myself...

I also found during my investigations that neon and wxGTK also have similar
problems, but given the enthusiasm this bug has been met with, I'm really not
sure I'll bother pestering the other package maintainers.  Do what you will
with the bug now, there is at least a patch if this ever causes people problems
again...

i totally agree with you.

unfortunatly sometimes i "ping" with the intent to spam and reacivate some bugs
that seems forgotten.

i don't want to criticize or blame, absolutly. just ping and wake up.

for the "close" issue, i said this because i saw a @gentoo.org dev asking for
closing.

i mean..i hate pending bugs.

tomorrow i'll test the patch.

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

This bug blocks the version bump for samba-3.2.x since compilation fails due to
--as-needed being at the wrong place.

Removed LDFLAGS from krb5-config "--libs" output for the latest unstable
release. I've only patched there to see if we produce a regression.

g, mueli

p.S.: Feel free to reopen bug if problem persists!