This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: General multilib of libgcc issue (was: ``Re: Threads vs hpux10'')


  > Hi (again) Jeff,
  > 
  > OK, I figured it out.  The above is true for libstdc++-v3 and other
  > recent language libraries when it is multilib'd but it is not true for
  > libgcc itself.  While looking at alphaev67-dec-osf5.1 (configuration
  > of --enable-threads=posix) for the first time since gcc 2.95.1 on
  > alpha-dec-osf4.0f, I see the same problem you encountered on HPUX10
  > (however, it doesn't produce a fatal bootstrap error on OSF).
FWIW, it doesn't product a bootstrap error on hpux10.20 either -- why?
Because nothing in the bootstrap process ever tries to link C++ code
and thus nothing ever links in the exception handling code from libgcc
which has the annoying references to the thread functions.

  > The root problem is that gthr-default.h is created only once in
  > $objdir/gcc instead of once per multilib configuration.
Correct.

  > Anyways, you wanted to know the better solution.  If libgcc were built
  > like every other multilib'd language library then gthr-default.h
  > should be created in $objdir/gcc/<multilib-directory>/libgcc once per
  > multilib configuration instead of once in $objdir/gcc .  Then,
  > $objdir/gcc/<multilib-directory>/libgcc should be added to the header
  > search path while building libgcc.
Interesting.  I hadn't thought of doing something like this; the question
is is it worth reworking the libgcc build to do this?  My gut feeling is
no since systems without weak symbol support are limited and decreasing
in popularity every day (hpux, aix, osf?)

I need to do something about hpux11 threads (once the magic CD with
the thread stuff arrives).  I may poke at your suggestion solution at
that time since I believe hpux11 has 3 different potential configurations.

  > Looking at gcc/configure.in and how gthr-default.h is currently
  > created before we even have an xgcc to report thread configuration
  > (compare and contrast to how it is done in libstdc++-v3, boehm-gc,
  > libjava), I suppose that your patch was as good as any until/if libgcc
  > multilib support is updated to support the use of different headers in
  > light of multilib options.
It was quick, dirty and simple.   The question is are there enough systems
in the same boat out there to warrant a slightly more complex, but also
more scalable solution.

  > Sorry to have raised a red herring with
  > your patch but I did learn how to multilib a configuration while
  > investigating this issue so it wasn't a total waste IMHO.
No worries.

  > [1] Should this program be linkable without error or warning on all
  >     platforms that properly support weak symbols?
  > 
  >     extern void f() __attribute__ ((weak));
  > 
  >     int main(){ if (f) f(); return 0; }
  > 
  >     It seems that OSF1 means something quite a bit different by weak
  >     than e.g. Solaris, FreeBSD or Linux...  It seems wrong to me for a
  >     feature exposed to the user to act so differently when mapped to
  >     different platform's native concept of weak...
Good question.  I don't know.  And yes, exposing "weak" symbols with
different behavior from one system to another isn't necessarily good.

That's largely why we don't have them on hpux -- SOM has the concept of
"secondary definitions" which have some similarities with weak symbols,
but also have a number of interesting (and for us, undesirable)
properties.   At first I thought we could emulate some basic weak symbol
support using secondary definitions, but ultimately I was wrong.

jeff



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