I started a configure with a configure I used the --with-ads --with-ldap --with-acl.. --with-pam --with-winbind --with smbmount flags to compile. The configure finished ok. I started The make. It finished on a error while compiling accross the CP850.so module. I'm using the redhat 9 distrib. The packaged binaries can be installed without problem. I will post the listing tomorrow.
Created attachment 661 [details] The configure listing with the options
Created attachment 662 [details] The make option with the listing
The two listings added to help debugging this reproductible failure.
what is the actual compile failure ? I see the warnings about unresolved symbols in the .so files. But they still link. Tim, any ideas on how to get rid of those warnings ?
This behaviour is reproductibe with no option at all !!!! It starts warning while compiling the recycle plugin.
Exact, I can find all my binaries. But the huge amount of warnings made me think It was an error. Something more, the return code ( echo $? = 127 ) It's not very good for an end of compile.... From my very poor point of view It seems some headers or includes missing ?
It's not really a compile error but some annoying warning message (reproducible on debian 3 stable). As seen in the log update for samba 3.0.7, it's the "BUG 1360: Need to use -Wl when passing flags to the linker" which causes the problem. Without -Wl in LDSHFLAGS (as in previous version), no warning at all. So if you want to keep this flag, you should find a way to get rid of this warnings.
I found that one way to have -Wl,-Bsymbolic without warning under linux (this ld option does not appear under FreeBSD samba 3.0.7 Makefile, so no warnings) is to add another option to the linker, -Wl,--allow-shlib-undefined Maybe a bad idea but it works under linux, the part of the Makefile which causes problem should be like that: LDSHFLAGS=-shared -Wl,-Bsymbolic -Wl,--allow-shlib-undefined WINBIND_NSS_LDSHFLAGS=-shared -Wl,-Bsymbolic -Wl,--allow-shlib-undefined
What does "référence indéfinie vers" actually mean? I don't get any of these warnings on any machines I have access to.
According to the manpage for ld on Linux, --allow-shlib-undefined is actually the default.
(In reply to comment #9) > What does "référence indéfinie vers" actually mean? I don't get any of these > warnings on any machines I have access to. "référence indéfinie vers" is a french expression for " No reference defined for". In my point of view, A "reference" is often the name for "a pointer". So I think, we should better look at the declaration of the variables part of this module ?
(In reply to comment #10) > According to the manpage for ld on Linux, --allow-shlib-undefined is actually > the default. You're partially right. It's the case for newer version of ld. According to cvs log, here is the date when it become the default: =================================================================== RCS file: /cvs/src/src/ld/ChangeLog,v retrieving revision 1.857 retrieving revision 1.858 diff -u -r1.857 -r1.858 --- src/ld/ChangeLog 2003/02/11 18:03:44 1.857 +++ src/ld/ChangeLog 2003/02/17 18:24:37 1.858 @@ -1,3 +1,11 @@ +2003-02-17 Nick Clifton <nickc@redhat.com> + + * ldmain.c (main) Default allow_shlib_undefined to true. + * lexsup.c (ld_options): Add --no-allow-shlib-undefined. + (parse_args): Parse the new switch. + * ld.texinfo: Document new switch and default behaviour of + allowing undefined symbols in shared libraries. + So older distribution like debian 3 stable or rh9 (probably) doesn't have it as a default option. I do really think the problem comes from this flag. (tested positive on debian stable).
(In reply to comment #10) > According to the manpage for ld on Linux, --allow-shlib-undefined is actually > the default. For your information, --allow-shlib-undefined is the default since binutils 2.14, if it can help for configure tests.
Created attachment 699 [details] Configure patch for linux which add the correct LDSHFLAGS according to the release date of GNU ld Patch for version 3.0.7 Samba users, make sure to run autoconf in the source directory before runnning ./configure Maybe a bad way to do this but it works...
Created attachment 701 [details] Same patch, added AC_MSG_... Exactly the same patch but display the check against gnu ld rel date. Probably more explicit than a quiet test
Created attachment 707 [details] Same patch, more in autoconf style date updated according to gnu ld cvs repository
*** Bug 1832 has been marked as a duplicate of this bug. ***
*** Bug 1833 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > Created an attachment (id=707) [edit] > Same patch, more in autoconf style > > date updated according to gnu ld cvs repository Thanks Michael. I have applied this patch.
does the patch fix the bug? If so, tim please close this out out as fixed.
Marking as fixed.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.