On Tue, 2 Mar 1999, Chuck Robey wrote: > On Tue, 2 Mar 1999, Doug Rabson wrote: > > > That was put in extremely recently. The reason it doesn't build a shared > > library by default is to avoid potential conflict with the system > > libstdc++. > > > > If you enable it, the port will install the shared lib in > > /usr/lib/gcc-lib/.../libstdc++.so. You may need to add a runpath option > > to your link to point the executable at the directory. > > Doug, my egcs (when I tell it to --enable-shared) installs: > > libstdc++.so > libstdc++.so.2.9 and > libstdc++.so.2.9.0 > > How about I just keep the first one, kill the middle one, and make the > real file libstdc++.so.3 (so it keeps our numbering). I'm not sure > about the rules for this, since elf ... will stuff looking for > libstdc++.so.2 find my new libstdc++.so.3, or will the new one (with > it's incompatible format, like you said) be safe?
It depends on the SONAME field inside the shared library. The full name of the lib needs to match the SONAME I think (which is libstdc++.so.2.9 in my build). I realise that the naming doesn't follow the ports tree rules for shared libs but it shouldn't cause conflicts if you use runpaths to point at its location. I use '-Wl,-rpath=/usr/local/lib/gcc-lib/...' when I link stuff that I want to use the shared lib. Hopefully, this is only a short term measure until we get the beast properly integrated into the build. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
