From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John David Anglin" To: law@cygnus.com Cc: jason@cygnus.com, gcc-patches@gcc.gnu.org, egcs-bugs@egcs.cygnus.com Subject: Re: g++-mike-eh8-C test failure Date: Tue, 02 May 2000 11:08:00 -0000 Message-id: <200005021808.OAA18067@hiauly1.hia.nrc.ca> References: <19962.957285066@upchuck> X-SW-Source: 2000-05/msg00106.html > In message <200004301546.LAA19936@hiauly1.hia.nrc.ca>you write: > > After all this grief with duplicate routines, I decided to change the > > hpux configuration for libstdc++ so that the standard libraries are not > > linked into libstdc++.sl. This resolves the problem. > And just adds a new set of problems. Consider if the library needs something > like __muldi3 -- you won't have it anymore after your change because you're > not linking in libgcc. > > Basically you've just exchanged one set of problems for an even worse set > of problems. No. "-nostdlib" is only used when building the shared varsion of libstdc++. When an app is linked with libstdc++, libgcc is normally included twice in the link (eg., without threads -lgcc -lc -lgcc is automatically included). With the change, I didn't encounter any link problems using the shared version of libstdc++ included with the gcc-2.95 branch except for the one case mentioned which involved threads and profiling. I am fairly certain if __muldi3 weren't being linked in from libgcc properly, something would have gone wrong in running the testsuite. The results with a shared libstdc++ were equivalent to that with the archive version. Thus, I don't see the worse set of problems that you describe with the hpux 10.20 linker. Have you a specific example that I can test? NB: I have installed the longjmp patch to pa.md which is now in the main branch but not the 2.95 branch, and a configure patch re DCE thread selection which fixes linking problems when DCE threads are installed. Thus, some of the problems previously observed may be fixed. The situation here is specific to the hpux som linker and its handling of global data in shared libraries. If libstdc++ is linked with libgcc when it is built, this has the unfortunate side effect of linking static procedures into a final app twice, once from libstdc++ and once from libgcc. Both get used. Which one is selected depends on the calling path. If the routine has data which shouldn't be duplicated, disaster ensues. In the particalur case studied, it was the global data symbol "__tic" which caused tinfo2.o to be loaded from libgcc rather than libstdc++. Possible solutions as I see it are: 1) Get HP to fix their linker. Doesn't seem likely. 2) Hack libstdc++ so that global data is only accessed in procedures with global scope. This is possible but more complicated than 3 below. 3) Don't link the shared version of libstdc++ with libgcc when it is built. I know there were problems on other systems (alpha?) when this was done. This needs to be looked into further under hpux but if you check the configuration files for libstdc++ you will see that openbsd uses the -nostdlib option when building the shared version of libstdc++. In summary, with the above mentioned patches installed in the gcc-2.95 branch, I find that the shared libstdc++ v2 is working equivalently to the archive version. The situation with the main branch is now under investigation. However, it looks like there are other problems which need resolution first. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)