The gcl-2.6.8-plt.patch patch is incorrect, and will generate a gcl binary that fails to build at least maxima and axiom, when using the newer binutil's ld. There is a blank line before the " .iplt" section in the linker map, and there are annotations, i.e. if the second character is not a blank, it is an annotation.
Created attachment 374311 [details] gcl-2.6.8-iplt.patch This patch should correct the issue. To check the mandriva gcl package, please check: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gcl/current/
Thank you very much for the patch. I will make new builds today for F-11+.
gcl-2.6.8-0.7.20090701cvs.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gcl-2.6.8-0.7.20090701cvs.fc12
gcl-2.6.8-0.5.20090701cvs.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gcl-2.6.8-0.5.20090701cvs.fc11
Thanks. Feel free to close the bug when appropriate. I suggest using "--enable-statsysbfd --disable-dynsysbfd" instead of "--disable-statsysbfd --enable-dynsysbfd", otherwise, gcl needs to be recompiled everytime binutils is updated (or risk have the package broken until someone notices it). Also, when linking with a dynamic libbfd, but not using the suggested patch, it was hiding the problem, as si:save-system was generating broken axiom binaries, that would crash when loading some .o modules. And, when using static or local libbfd it would fail to load modules due to missing libc symbols, but probably statically linking libc could have been another solution (more of a hack).
Land mines everywhere, huh? :-) It seems to me that the problem is that the libbfd dependency is not visible to rpm, so we don't get a versioned dependency on it. If I manually add such a versioned dependency to the spec file, then I'll get a broken dep message whenever there is a binutils update. I'll have to ponder all the ways this can break and choose the least dangerous path. Thanks for your input.
gcl-2.6.8-0.7.20090701cvs.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gcl'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12489
gcl-2.6.8-0.5.20090701cvs.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gcl'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-12507
I'm talking nonsense in comment 6. This is the contents of /usr/lib64/libbfd.so: ------------------------------------------------------------------------------ /* GNU ld script */ /* Ensure this .so library will not be used by a link for a different format on a multi-architecture system. */ OUTPUT_FORMAT(elf64-x86-64) /* The libz dependency is unexpected by legacy build scripts. */ INPUT ( /usr/lib64/libbfd.a -liberty -lz ) ------------------------------------------------------------------------------ All I'm doing by configuring gcl for dynamic libbfd is avoiding the necessity of hacking up the makefiles to add -lz. RPM doesn't detect the libbfd dependency because gcl isn't linked to it statically. Use of ldd confirms this. So the suggestion in comment 5 accomplishes nothing, and the recent breakage was NOT due to dynamic linking of libbfd. I figured this all out about a year ago and then promptly forgot about it. :-)
I was talking somewhat based on Mandriva file system :-) libbfd.so used to be a symlink to the "versioned" libbfd-version-date-tag.so, then, for a few days there was no more libbfd.so, and then after some talk with the binutils maintainer a linker script was added, like the one in Fedora. The breakage was just due to linker map format change, what caused the previous parser to not find symbols under " .iplt". The gcl configure script appears to automatically add libz, but maybe I am missing something, or problem in another place gcl is used.
You're right. That part of the configure script didn't exist last year when I took over maintenance of the gcl package. It was added upstream early in 2009 sometime, if my memory isn't entirely faulty. (It may be.) So at this point, there should be no difference at all between configuring for static or dynamic libbfd. And thanks to the patch you supplied, our PLT woes should be at an end too, I hope. Thanks again for your help.
gcl-2.6.8-0.5.20090701cvs.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
gcl-2.6.8-0.7.20090701cvs.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.