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

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

[Manfred Hollstein]

Hi,

I'm just trying to build egcs using:

$ env CC=gcc CFLAGS=-O   LDFLAGS=-s INSTALL="/tools/gnu/bin/install -c" INSTALL_DATA="/tools/gnu/bin/install -c -m 644" INSTALL_PROGRAM="/tools/gnu/bin/install -c -m 755" /bin/sh ../egcs-970929/configure sparc-sun-sunos4.1.4 --srcdir=../egcs-970929 --prefix=/u/b60/manfred/gnu/sparc-sun-sunos4 --with-gnu-as --enable-shared --with-gxx-include-dir='/u/b60/manfred/gnu/sparc-sun-sunos4/lib/gcc-lib/sparc-sun-sunos4.1.4/egcs-2.90.11/include/g++' --with-local-prefix=/u/b60/manfred/gnu/sparc-sun-sunos4 --verbose

Building the compiler went  fine, but building the shared  libstdc++'s
fails miserably:

/u/b60/manfred/work/GNU/egcs-970929-sparc-sun-sunos4.1.4/gcc/xgcc -B/u/b60/manfred/work/GNU/egcs-970929-sparc-sun-sunos4.1.4/gcc/ -g -O2 -fno-implicit-templates  -fpic -fPIC -shared -o libstdc++.so.2.8.0 `cat piclist` 
ld: /u/b60/manfred/work/GNU/egcs-970929-sparc-sun-sunos4.1.4/gcc/libgcc.a(_eh.o): assert pure-text failed: reference to [offset] at 1f874 in /u/b60/manfred/work/GNU/egcs-970929-sparc-sun-sunos4.1.4/gcc/libgcc.a

ld: /u/b60/manfred/work/GNU/egcs-970929-sparc-sun-sunos4.1.4/gcc/libgcc.a(_eh.o): assert pure-text failed: reference to [offset] at 1f878 in /u/b60/manfred/work/GNU/egcs-970929-sparc-sun-sunos4.1.4/gcc/libgcc.a

[lots of messages deleted]

There seem to be two problems:

  1. PICFLAG=-fPIC
     is declared unconditionally although this should come from the
     multilib stuff

  2. $ ./xgcc -B./ --print-multi-lib
     .;
     pic;@fpic		# Error occurs here
     ucpic;@fPIC
     v8;@mcpu=v8
     pic/v8;@fpic@mcpu=v8
     ucpic/v8;@fPIC@mcpu=v8

     Why is xgcc using libgcc.a from ${libsubdir} instead of
     ${libsubdir}/pic ?

Can anybody who believes  to  have built a  shared libstdc++  on SunOS
successfully shed some light on this?

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

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

[Alexandre Oliva]

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.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

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

[Manfred Hollstein]

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

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

[Manfred Hollstein]

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