Bug 6984 - Build fails on RHEL 5 and Slackware 12.1 w/readline 5.2
Build fails on RHEL 5 and Slackware 12.1 w/readline 5.2
Status: RESOLVED WONTFIX
Product: Samba 3.5
Classification: Unclassified
Component: Build environment
3.5.0pre1
x86 Linux
: P3 normal
: ---
Assigned To: Guenther Deschner
Samba QA Contact
:
: 7482 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-10 07:13 UTC by Karolin Seeger
Modified: 2016-11-01 21:21 UTC (History)
2 users (show)

See Also:


Attachments
config.log.gz (156.50 KB, application/x-gzip)
2009-12-10 07:16 UTC, Karolin Seeger
no flags Details
output of ./configure && make (26.78 KB, application/octet-stream)
2009-12-10 07:17 UTC, Karolin Seeger
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karolin Seeger 2009-12-10 07:13:49 UTC
Build fails on RHEL 5 with:

rhel5-i386[chroot]:/usr/src/redhat/SOURCES/samba-3.5.0pre1/source3# ./configure && make
[...]
Linking bin/smbclient
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `PC'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetflag'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetent'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `UP'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tputs'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgoto'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetnum'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `BC'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status
make: *** [bin/smbclient] Error 1
Comment 1 Karolin Seeger 2009-12-10 07:16:38 UTC
Created attachment 5078 [details]
config.log.gz
Comment 2 Karolin Seeger 2009-12-10 07:17:31 UTC
Created attachment 5079 [details]
output of ./configure && make
Comment 3 Björn Jacke 2009-12-10 08:41:14 UTC
rhel5-i386[chroot]:/# ldd -u /usr/lib/libreadline.so.5
     21536:     /usr/lib/libreadline.so.5: error: symbol lookup error: undefined symbol: BC (continued)
undefined symbol: BC    (/usr/lib/libreadline.so.5)
     21536:     /usr/lib/libreadline.so.5: error: symbol lookup error: undefined symbol: PC (continued)
undefined symbol: PC    (/usr/lib/libreadline.so.5)
     21536:     /usr/lib/libreadline.so.5: error: symbol lookup error: undefined symbol: UP (continued)
undefined symbol: UP    (/usr/lib/libreadline.so.5)
rhel5-i386[chroot]:/# ldd -u /usr/lib/libreadline.so.5.1
     21542:     /usr/lib/libreadline.so.5.1: error: symbol lookup error: undefined symbol: BC (continued)
undefined symbol: BC    (/usr/lib/libreadline.so.5.1)
     21542:     /usr/lib/libreadline.so.5.1: error: symbol lookup error: undefined symbol: PC (continued)
undefined symbol: PC    (/usr/lib/libreadline.so.5.1)
     21542:     /usr/lib/libreadline.so.5.1: error: symbol lookup error: undefined symbol: UP (continued)
undefined symbol: UP    (/usr/lib/libreadline.so.5.1)

are there RHEL5 update packages that fix this problem? (assigning to gd :-)
Comment 4 Björn Jacke 2009-12-10 16:58:53 UTC
see also:

https://bugzilla.redhat.com/show_bug.cgi?id=499837

... currenty STATUS NOTABUG for Red Hat.

Definetely not a bug for us, too. People who want to build on a broken RHEL5 system will have to set LDFLAGS/LDSHFLAGS manually to ignore unresolved symbols.
Comment 5 Milan Kerslager 2010-03-08 10:32:47 UTC
As of comment #1 at https://bugzilla.redhat.com/show_bug.cgi?id=499837, this should be handled in configure script in Samba itself, because RHEL5 support both libtermcap or libncurses and this is up to application to pick proper one.

RHEL5 is unable to make one preffered because this would break other applications (which prefer other library).

So please make a logic in configure script to pass proper parameter to build Samba package (bacause tehere are two possibilities and only application knows correct one).
Comment 6 Milan Kerslager 2010-03-08 10:35:08 UTC
Please reopen this bug (as I explained above). Thank you.
Comment 7 Simo Sorce 2010-03-08 11:19:40 UTC
agreed
Comment 8 Karolin Seeger 2010-03-08 12:24:25 UTC
*** Bug 7209 has been marked as a duplicate of this bug. ***
Comment 9 Eero Tamminen 2010-04-25 05:18:04 UTC
(In reply to comment #5)
> As of comment #1 at https://bugzilla.redhat.com/show_bug.cgi?id=499837, this
> should be handled in configure script in Samba itself, because RHEL5 support
> both libtermcap or libncurses and this is up to application to pick proper
> one.
> 
> RHEL5 is unable to make one preffered because this would break other
> applications (which prefer other library).

But linking things directly in the application (potentially) has this exact same breakage on the distributions which actually do things sensibly.

This is definitely a bug in RHEL.  Debian solved this issue (trivially) already in 90's, see my comment in the RedHat bug.
Comment 10 Milan Kerslager 2010-04-26 01:43:09 UTC
1) Debian is unable to solve this.
2) Debian may contain a lot of similar libraries and there is no way to pick up the ONE as enforcement defalult as it may break because of code from app developer is coded for another similar library.
3) Configure script should detect this and solve this (as does in other cases).
4) The (build) system should not make a default because this could be wrong default.
5) Configure script is the right place as developers know what library is correct.
6) SPEC file in RPM or compile script in DEB is the wrong place as this is harcoded and unusable for anyone who wish to build from source for itself.
Comment 11 Guenther Deschner 2010-05-31 14:23:46 UTC
*** Bug 7482 has been marked as a duplicate of this bug. ***
Comment 12 Michael Adam 2016-11-01 21:21:31 UTC
Apologies for not having fixed this...
Version 3.5 is long out of support.
I am closing this bug.
New versions of Samba use a completely different build system.
If similar problems exist in current code, please open a new bug.

Thanks!