Re: egcs-970929: SunOS and --enable-shared - HOW?

[Manfred Hollstein <manfred at ks dot sel dot alcatel dot de>]

Somehow I have  the impression that my  reply didn't make  it into the
mailing list; hence I'm  posting it again   - if it still  arrived the
first time, please excuse the duplication.

BTW, I'm  just  trying my  proposal  below, and  it  seems to work  OK
(seems,  because the  SunOS build  is   still running; Solaris   build
finished successfully with  the exception of the compilation/execution
errors  in tstring). If  everything succeeds,  I'll send  a patch next
week.

Have a nice weekend.  Manfred

PS: Alexandre, what's your official e-mail address? I received the
    following from our postmaster:

This report relates to your message: Subject: Re: egcs-970929: SunOS and --enable-shared - HOW?,
  Message-ID: <9710100747.AA09822@lts.sel.alcatel.de>,
  To: oliva@dcc.unicamp.br
        of Fri, 10 Oct 1997 09:47:38 +0200

Your message was not delivered to   oliva@dcc.unicamp.br
        for the following reason:
        Unknown Address
        MTA 'mailrelay1.alcatel.de' gives error message  Unknown
        domain 'dcc.unicamp.br' 



On , 9 October 1997, 06:18:16, oliva@dcc.unicamp.br wrote:

    Manfred Hollstein writes:
    
    > Can anybody who believes  to  have built a  shared libstdc++  on SunOS
    > successfully shed some light on this?
    
    I build egcs with shared libraries regularly on SunOS 4.1.3
    
    The only non-trivial trick I use is to create a soft-link
    egcs-<date>/gcc/real-ld -> GNU ld.  I also create such links in the
    several stage subdirectories.
    
Thanks, I just tried it, and it doesn't fail now. BUT, it's not correct:

Take a look at the command line how the various libstdc++.so get built

$ /u/b60/manfred/work/GNU/egcs-971008-sparc-sun-sunos4.1.4/gcc/xgcc -B/u/b60/manfred/work/GNU/egcs-971008-sparc-sun-sunos4.1.4/gcc/ -g -O2 -fno-implicit-templates  -fpic -mcpu=v8 -fPIC -shared -o libstdc++.so.2.8.0 `cat piclist` 

As you can see, both `-fpic' and `-fPIC' are used; the former comes from

  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \

while the latter comes hardcoded from config/mh-sparcpic which defines

PICFLAG=-fPIC

What we end up with is shared libs all built with -fPIC instead of what was
intended by --print-multi-lib.

The problem here is, that $(PICFLAG) overrides everything that the multilib stuff
defines different. Even more, since both flags are used, (x)gcc fails to add the
proper -L<directory-which-contains-the-appropriate-libgcc.a> hence using the
libgcc.a in ${libsubdir} which hasn't been built using any pic flags :-( This is
the reason, why it fails with SunOS's native ld. It doesn't fail with GNU ld,
because:

`-assert KEYWORD'
     This option is ignored for SunOS compatibility.

IMHO, we have to find a way

  - to ignore what PICFLAG defines if the passed multi-lib options include
    any pic related option
  - and to use PICFLAG, if the multi-lib options don't include any pic flags.

Yesterday, I tried various hacks, but they all fail, because PICFLAG is
contained in FLAGS_TO_PASS; if we omit it there, we could use something like

PICFLAG = `if test -z "${MULTISUBDIR}"; then echo -fPIC; else case "${LIBCFLAGS} ${LIBCXXFLAGS}" in *-fpic* ) echo -fpic ;; * ) echo -fPIC ;; esac; true; fi`

in config/mh-sparcpic letting every subdir Makefile define PICFLAG properly.

What do you think?

--
 Manfred Hollstein                               Alcatel, Dept. US/EC4
 <mailto:manfred@lts.sel.alcatel.de>             Lorenzstrasse 10
                                                 70435 Stuttgart
 Public PGP key on request                       Germany