This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: g++-mike-eh8-C test failure



  In message <200005021808.OAA18067@hiauly1.hia.nrc.ca>you write:
  > No.  "-nostdlib" is only used when building the shared varsion of libstdc++
And that is precisely the problem.  That change is _wrong_, no ifs ands or
butts about it.

  > 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.
Consider a shared library that does not appear on the link line, but which
is loaded explicitly by the application.

If the shared library references __muldi3, but the main application and
libraries on the link line for the application do not, then no __main will
be linked into the final executable.

So when you do a shl_load to suck in the shared library we'll have an
undefined reference to __muldi3 and we'll lose badly.


  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?
See above.

Never assume that just because something passes the testsuite that it is
correct.  There are numerous things the testsuite does not check.


  > 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++.
4. Build a shared libgcc and have it referenced by either the main program
or the library.  Which is precisely what we're discussing in another thread.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]