Bug 256281 - gcl: version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
gcl: version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
x86_64 All
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-27 07:57 EDT by Rex Dieter
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-28 17:25:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2007-08-27 07:57:40 EDT
using gcl-2.6.7-15.fc8.x86_64

Trying to build maxima, but fails on x86_64 during its configure stage checking
for gcl:
...
clisp runtime is "/usr/lib64/clisp/base/lisp.run"
/usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl: relocation error:
/usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl: symbol personality, version
GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
configure: error: unable to run gcl executable "gcl".
error: Bad exit status from /var/tmp/rpm-tmp.10829 (%build)

Full failed build.log:
http://koji.fedoraproject.org/koji/getfile?taskID=131335&name=build.log

Now, I'm not sure this is necessarily gcl's fault, because I see the last change
to gcl was made on Aug 14 (according to changelog), but I had a successful
maxima build very recently (a couple of days ago):
http://koji.fedoraproject.org/koji/buildinfo?buildID=16162
and it too used gcl-2.6.7-15.fc8.x86_64

Any ideas what's going on here?
Comment 1 Rex Dieter 2007-08-27 08:03:09 EDT
maybe glibc?  it was updated Aug 25, and included in its changelog (x86_64-related):
- readd x86_64 gettimeofday stuff, initialize it earlier

maybe try rebuilding gcl?
Comment 2 Rex Dieter 2007-08-27 08:14:44 EDT
reassigning glibc...
Comment 3 Rex Dieter 2007-08-27 09:03:27 EDT
Tried rebuilding gcl, and now it fails:

cp init_pre_gcl.lsp.in init_pre_gcl.lsp.tmp
touch raw_pre_gcl_map
gcc -o raw_pre_gcl  \
                -L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp
/usr/lib64/libbfd.a /usr/lib64/libiberty.a -lreadline -lncurses
 -lncurses -lc -lgclp
./libpre_gcl.a(main.o): In function `main':
/builddir/build/BUILD/gcl-2.6.7/o/main.c:132: undefined reference to `personality'
/builddir/build/BUILD/gcl-2.6.7/o/main.c:135: undefined reference to `personality'
collect2: ld returned 1 exit status
make[1]: *** [raw_pre_gcl_map] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/gcl-2.6.7/unixport'
make: *** [unixport/saved_pre_gcl] Error 2
Comment 4 Gérard Milmeister 2007-08-27 12:01:27 EDT
This is due to hack to change personality, something to do with executable heap
(randomized address), I think. The personality function is in
/usr/include/sys/personality.h. Probably something changed with the libc?
Comment 5 Jakub Jelinek 2007-08-28 17:25:45 EDT
Should be fixed in glibc-2.6.90-13.

Note You need to log in before you can comment on or make changes to this bug.