* Re: egcs-970929: SunOS and --enable-shared - HOW?
1997-10-09 2:08 ` Alexandre Oliva
@ 1997-10-10 8:51 ` Manfred Hollstein
1997-10-10 8:51 ` Manfred Hollstein
1 sibling, 0 replies; 4+ messages in thread
From: Manfred Hollstein @ 1997-10-10 8:51 UTC (permalink / raw)
To: aoliva; +Cc: egcs
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: egcs-970929: SunOS and --enable-shared - HOW?
1997-10-09 2:08 ` Alexandre Oliva
1997-10-10 8:51 ` Manfred Hollstein
@ 1997-10-10 8:51 ` Manfred Hollstein
1 sibling, 0 replies; 4+ messages in thread
From: Manfred Hollstein @ 1997-10-10 8:51 UTC (permalink / raw)
To: oliva; +Cc: egcs
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
^ permalink raw reply [flat|nested] 4+ messages in thread