Red Hat Bugzilla – Bug 84885
libstdc++ rpm does not create generic symlinks to actual lib names.
Last modified: 2008-05-01 11:38:05 EDT
Description of problem:
When libraries are installed, generic symlinks are created to point to the
actual lib name. ld looks for these generic names. This is good, as ld doesn't
have to be reconfigured every time a library is updated or the name changes
Unfortionatly, libstdc++ doesn't create these libs, and thus, any application
that would like to include libstdc++ when linking, will fail.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install libstdc++
2. run ld -lstdc++
Actual Results: [root@yoda root]# ld -lstdc++
ld: cannot find -lstdc++
Expected Results: ld should find the library, and in this example, bail out due
to no other input:
[root@yoda root]# ld -lstdc++
ld: warning: cannot find entry symbol _start; not setting start address
To get ld working correctly, all I did was create 2 symbolic links.
/usr/lib/libstdc++.a and /usr/lib/libstdc++.so. These pointed to the actual
library files accordingly.
I was able to duplicate this bug in 7.3 and 7.2, not sure if it exists any
farther back, or forward.
It is on purpose. First of all, ld shouldn't be used directly to link libraries
or binaries, that's what gcc/g++ driver is for.
And there is really no THE libstdc++, but each compiler has its own.
So which libstdc++ are you linking against depends on which compiler are you
using (g++, g++296, something else).
So, since the compile of php didn't complete, and I was using gcc, and the php
spec file from 7.3 with the latest 4.3.1 php source, where would the problem
lie? The spec file? The RPM macros? The php source? I'm just trying to
figure where I can file this bug, so that other people spend a long time trying
to figure out why php won't compile correctly.
Of note, when doing a straight ./configure and make of php (no special options)
I did not run into this problem. It was only when building via the rpm spec file.