Hide Forgot
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 slightly. 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): How reproducible: Always 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 Additional info: 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.