multilib and shared libs problems in sco-3.2v5.0.4

multilib and shared libs problems in sco-3.2v5.0.4

[Joao Cardoso]

Hi,

sco-3.2v5.0.4 is a multilib platform, with both coff and elf support.

By default, `configure' on egcs-1.0.2 builds in multilib mode. No
apparent problem here, except that gcc/pic/libgcc.a has several coff
files in it. They are:

_adddf3.o _addsf3.o _ashlsi3.o _ashrsi3.o _divdf3.o _divsf3.o _divsi3.o
_eqdf2.o _eqsf2.o _extendsfdf2.o _fixdfsi.o _fixsfsi.o _floatsidf.o
_floatsisf.o _gedf2.o _gesf2.o _gtdf2.o _gtsf2.o _ledf2.o _lesf2.o
_lshrsi3.o _ltdf2.o _ltsf2.o _modsi3.o _muldf3.o _mulsf3.o _mulsi3.o
_nedf2.o _negdf2.o _negsf2.o _nesf2.o _subdf3.o _subsf3.o _truncdfsf2.o
_udivsi3.o _umodsi3.o

and are build by the host cc compiler:

for name in _mulsi3 _udivsi3 _divsi3 _umodsi3 ...
do \
  echo ${name}; \
  rm -f ${name}.o; \
  cc -DIN_LIBGCC1  -I. -I/src/compilers/egcs-1.0/gcc
-I/src/compilers/egcs-1.0/gcc/config -c -DL${name}
/src/compilers/egcs-1.0/gcc/libgcc1.c; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  mv libgcc1.o ${name}.o; \
  ar qc tmplibgcc1.a ${name}.o; \
  rm -f ${name}.o; \
done

As the host compiler support both coff and elf, there are no reasons to
not build the elf version, being enought to supply a `-belf' to `cc'.
This cannot be bypassed by `CC="cc -belf" make bootstrap', as OLDCC
is used for compiling; perhaps setting CCLIBFLAGS? But two sets of the
above functions should be generated, one with `cc -belf' the other
with `cc -bcoff'.
Also, it is wrong not to supply a `-bcoff' or `-belf' to `cc' above,
as there exist a global cc configuration file that the user might have
changed to build elf or coff by default. 

This is no big matter, as at runtime the host's loader convert coff
to elf, but I reported it just for completness...

Aside note-1:
This would be a problem if a libgcc.so were build. (Why not? although
small, libgcc.a is linked with all gcc build programs, so making a
shared version would be a great(?) space saving).

Aside note-2:
Why isn't a shared libf2c build?

Well, back to shared libs and multilib.
As I want a libstdc++.so, I tried `configure --enable-shared'. Helas!
The build stop with an error when trying to compile, in libraries/coff,
a shared coff object file, supplying `-mcoff -fpic' to the compiler!
The error says: `-fpic is not valid with -mcoff', which comes from
the `specs' file for building gcc in sco, which is correct.
The problem comes from FLAGS_TO_PASS that has PICFLAGS set to -fpic.
With some hacking, which I enclose below, I was able to bypass this
problem, but than another problem arose: the build tries to build
both a static and a shared library in both the pic and the coff
libraries subdirectories:
 
make[4]: Leaving directory
`/src/compilers/egcs-1.0-build/libraries/coff/libio'
/src/compilers/egcs-1.0-build/gcc/xgcc
-B/src/compilers/egcs-1.0-build/gcc/ -g -O2 -fno-implicit-templates
-mcoff -G -h libstdc++.so.2.8.0 -o libstdc++.so.2.8.0 `cat piclist`
i386ld *command line*: unknown flag: h
i386ld *command line* fatal: Can't open file libstdc++.so.2.8.0 for
input
collect2: ld returned 13 exit status
make[3]: *** [libstdc++.so.2.8.0] Error 1
make[3]: Leaving directory
`/src/compilers/egcs-1.0-build/libraries/coff/libstdc++'
make[2]: *** [multi-do] Error 1

this time supplying `-mcoff -G', whis is incompatible (-G is the
option to build a shared lib; $(SHFLAGS) and -shared also appeared
together before my hack.) This happened because I specified
both ARLIB and SHLIB as targets to libstdc++. Another hack correct
this, disabling the target SHLIB in a coff directory.

It seems to me that the only real solution will be to specify both the
compile options and targets for each subdirectory when doing multilib
(but I don't have the expertise). Also, in the gcc configuration, there
exist a set of multilib options that could solve this problem,
MULTILIB_EXCEPTIONS, MULTILIB_DIRNAMES, etc. Why are they not used?

Another possible solution would be to distribute a last resource normal
`configure' in libstdc++, so one could just `./configure --enable
shared' in libstdc++.

`configure --enable-shared --disable-multilib' builds OK, except that no
libstdc++.so.2.8.0 was generated; one has to cd to libstdc++ and `make
libstdc++.so.2.8.0' to build it. This was before applying my hacks.

I always used a separate build directory.

Summary: on sco-3.2v5.0.4, one should build:

coff/libstdc++.a   compiled with `-mcoff' and build with `ar'
pic/libstdc++.a    compiled with `-melf' and build with `ar'
pic/libstdc++.so   compiled with `-melf -fpic' and build with `gcc -G'

The enclose files are *hacks*, not real solutions, and its purpose
is only to ilustrate the problem of generating shared libs in a multilib
environment such as sco3.2v5.0.4.

After building, another question arise: if I want to manually install a
libstdc++.so,  which of them shall I install? They seem to be different!

 ... 395856 May 03 09:33 ./libraries/pic/libstdc++/libstdc++.so.2.8.0
 ... 394884 May 03 09:32 ./libraries/libstdc++/libstdc++.so.2.8.0
     ^^^^^^
 
Also, `make check' fails in all g++ tests! It suceed if I correctly
set LD_LIBRARY_PATH to `pwd`/libraries/libstdc++. The -L is setup, but
not LD_LIBRARY_PATH. SCO `ld' don't have a `-rpath' option.

The libstdc++ tests don't suffer from this problem, although some of
the tests fail with the shared library and not with the static one.

       === libio tests ===
...
FAIL: tFile.cc execution
FAIL: tFile.cc execution -b0
FAIL: tFile.cc execution -b3

>>>>>>>>> I only type `a'<CR>, then it proceeds, without asking for more input.
>>>>>>>>> This does not happen if I staticaly link it. Then, the test runs OK.

Hello, world via cout
Hello, world via cerr
enter a char:a
c = "a"
enter three integers (short, int, long):first  = 2053 via dec =     2053
second = 1627706636 via form = 1627706636 = 014101152414 via cout.form =
1627706636 = 0x6104d50c
third  = 134523075 via hex = 804a8c3
tFile.cc:100: failed assertion `cin.good()'
ABORT instruction (core dumped)

...
        === libio Summary ===

# of expected passes        34
# of unexpected failures    3 
# of expected failures      3 
...

        === libstdc++ tests ===
...
FAIL: tcomplex.cc output
FAIL: tcomplex.cc -O output

>>>>>>>>> The problem here is introducing a space:

enter a complex number in form a or (a) or (a, b): (1.2, -34)
number = (0.560976,0.0487805)

enter a complex number in form a or (a) or (a, b): (1.2,-34)
number = (1.2,-34)

FAIL: tstring.cc execution 
FAIL: tstring.cc -O execution

>>>>>>>>> linking this one with the static lib poses no problem

n = 20 atoi(n) = 0 atof(n) = 0
tstring.cc:66: failed assertion `i == 20'
ABORT instruction (core dumped)


        === libstdc++ Summary ===

# of expected passes        24
# of unexpected failures    4 
# of expected failures      2 

        === gcc Summary ===

# of expected passes        4883
# of expected failures      5
# of unsupported tests      7

        === g++ tests ===
...
XPASS: g++.jason/destruct3.C - (test for bogus messages, line 38)
FAIL: g++.law/profile1.C (test for excess errors)
XPASS: g++.mike/dyncast1.C  Execution test
XPASS: g++.mike/dyncast2.C  Execution test

        === g++ Summary ===

# of expected passes        3398
# of unexpected failures    1   
# of unexpected successes   3   
# of expected failures      81
# of untested testcases     6

        === g77 tests ===
...
FAIL: g77.f-torture/execute/dnrm2.f execution,  -O2 -fomit-frame-pointer
-finli$
FAIL: g77.f-torture/execute/dnrm2.f execution,  -O2 -fomit-frame-pointer
-finli$

        === g77 Summary ===

# of expected passes        130
# of unexpected failures    2  


Aside note-3: having an installed egcs, do I need to do a `make
bootstrap'? all the above builds took hours -- is there a fast way?
perhaps just `make'?

Thanks,
Joao

-- 
Joao Cardoso, INESC  |  e-mail: jcardoso@inescn.pt
R. Jose Falcao 110   |  tel:    + 351 2 2094345
4050 Porto, Portugal |  fax:    + 351 2 2008487

Re: multilib and shared libs problems in sco-3.2v5.0.4

[Robert Lipe]

Joao Cardoso wrote:

> sco-3.2v5.0.4 is a multilib platform, with both coff and elf support.

If Kean and I knew three years ago what we knew now, it probably 
wouldn't be...

> By default, `configure' on egcs-1.0.2 builds in multilib mode. No
> apparent problem here, except that gcc/pic/libgcc.a has several coff
> files in it. They are:

I don't believe this is true if you follow the instructions and do a
'make bootstrap', is it?  I just looked in mine and it isn't.

> is used for compiling; perhaps setting CCLIBFLAGS? But two sets of the
> above functions should be generated, one with `cc -belf' the other
> with `cc -bcoff'.

If you do a 'make bootstrap', sets should be built with ./xgcc with 
appropriate options for ELF, COFF, and ELF PIC.

> This is no big matter, as at runtime the host's loader convert coff
> to elf, but I reported it just for completness...

It's not quite that clean.  ELF and COFF use different formats for things
like constructors and destructors.   Letting the linker convert things
on the fly will suprise you in bad ways when you try mixing them.

> Why isn't a shared libf2c build?

The fortran crowd knows that libf2c isn't multilibbed.    It just hasn't
floated to the top of anybody's todo list.   Patches would surely be 
welcomed.

> Well, back to shared libs and multilib.
> As I want a libstdc++.so, I tried `configure --enable-shared'. Helas!

This is known to not currently work on OpenServer.   Fixing it so that
it works correctly through a bootstrap isn't trivial, but it shouldn't
be impossible.   The problem is that during the bootstrap exercise if 
you're starting the build with the native compiler (or even with older 
GCC's) that all the flags for things like -G  and -melf keep changing 
under you with progressive stages of the bootstrap.   The number of 
available combinations is icky.

> The enclose files are *hacks*, not real solutions, and its purpose
> is only to ilustrate the problem of generating shared libs in a multilib
> environment such as sco3.2v5.0.4.

There are indeed a number of issues.   Until they're addressed correctly,
perhaps we should just stick a "--enable-shared is not supported on this
target" flag on it.

> Also, `make check' fails in all g++ tests! It suceed if I correctly
> set LD_LIBRARY_PATH to `pwd`/libraries/libstdc++. The -L is setup, but
> not LD_LIBRARY_PATH. SCO `ld' don't have a `-rpath' option.

It passes almost all of the tests without all this hackery.   To get a 
functioning set of tools you'll need to either finish the work you started
to make --enable-shared fully work or disable the --enable-shared flag.

> Aside note-3: having an installed egcs, do I need to do a `make
> bootstrap'? all the above builds took hours -- is there a fast way?
> perhaps just `make'?

Citing install.texi:
	@item i386-*-sco3.2v5*
	Use this for the SCO OpenServer Release family including 5.0.0, 5.0.2,
	5.0.4, Internet FastStart 1.0, and Internet FastStart 1.1.
	[ munch ] 
	@emph{NOTE:} You must follow the instructions about invoking
	@samp{make bootstrap} because the native OpenServer compiler builds
	a @file{cc1plus} that will not correctly parse many valid C++ programs.
	You must do a @samp{make bootstrap} if you are building with the native
	compiler.

You've also just discovered more reasons why a 'make bootstrap' really 
is necessary.   The build knows that egcs defaults to ELF, so it doesn't
bother specifying the flags.  (And If it did, a bootstrap would fail 
becuase '-melf' would choke /bin/cc.)   So you're going to get a 
hodgepodge of ELF and COFF in your libraries.

Alternately, bootstrap EGCS once, do a 'make install' on it, then let
configure use it.  

Welcome to the sandpit...

RJL

Re: multilib and shared libs problems in sco-3.2v5.0.4

[Joao Cardoso]

Robert Lipe wrote:
> 
...
> > By default, `configure' on egcs-1.0.2 builds in multilib mode. No
> > apparent problem here, except that gcc/pic/libgcc.a has several coff
> > files in it. They are:
> 
> I don't believe this is true if you follow the instructions and do a
> 'make bootstrap', is it?  I just looked in mine and it isn't.

Perhaps I used the word multilib wrongly? I am not a computer scientist,
nor a programmer. To be shure, I removed the source and objdir of a
plain egcs-1.0.2, created then again, then

# mkdir egcs-1.0-objdir	# really 1.0.2
# cd egcs-1.0-objdir	
# CC=cc /src/egcs-1.0/configure	# I have egcs already installed
# make bootstrap
... wait a while (PII-266 with 2940UW :))
#find . -name \*.a

./libraries/libio/libio.a
./libraries/libio/libiostream.a
./libraries/coff/libio/libio.a
./libraries/coff/libio/libiostream.a
./libraries/coff/libiberty/libiberty.a
./libraries/coff/libstdc++/libstdc++.a
./libraries/pic/libio/libio.a
./libraries/pic/libio/libiostream.a
./libraries/pic/libiberty/libiberty.a
./libraries/pic/libstdc++/libstdc++.a
./libraries/libiberty/libiberty.a
./libraries/libstdc++/libstdc++.a
./libiberty/libiberty.a
./texinfo/libtxi/libtxi.a
./gcc/stage1/libgcc.a
./gcc/stage2/libf2c.a
./gcc/stage2/libgcc.a
./gcc/stage2/libobjc.a
./gcc/libgcc1.a
./gcc/libgcc.a
./gcc/coff/libgcc.a
./gcc/pic/libgcc.a
./gcc/libobjc.a
./gcc/libf2c.a

# file gcc/xgcc 
gcc/xgcc:       ELF 32-bit LSB executable 80386

This isn't multilib? It created both coff and elf versions of the
libraries.

> > is used for compiling; perhaps setting CCLIBFLAGS? But two sets of the
> > above functions should be generated, one with `cc -belf' the other
> > with `cc -bcoff'.
> 
> If you do a 'make bootstrap', sets should be built with ./xgcc with
> appropriate options for ELF, COFF, and ELF PIC.

# cd gcc/pic/
# ar x libgcc.a 
# file *| fgrep COFF
_adddf3.o:      iAPX 386 COFF object file not stripped - version 30821
_addsf3.o:      iAPX 386 COFF object file not stripped - version 30821
...
_udivsi3.o:     iAPX 386 COFF object file not stripped - version 30821
_umodsi3.o:     iAPX 386 COFF object file not stripped - version 30821

# rm *.o
# cd ..
# l *.a
-rw-r--r--   1 root     sys      2892716 May  4 20:17 libf2c.a
-rw-r--r--   1 root     sys       223162 May  4 20:02 libgcc.a
-rw-r--r--   1 root     sys        19298 May  4 19:44 libgcc1.a
-rw-r--r--   1 root     sys       537736 May  4 20:15 libobjc.a
# mkdir tmp
# cd tmp
# ar x ../libgcc.a 
# file *| fgrep COFF
_adddf3.o:      iAPX 386 COFF object file not stripped - version 30821
_addsf3.o:      iAPX 386 COFF object file not stripped - version 30821
...
_udivsi3.o:     iAPX 386 COFF object file not stripped - version 30821
_umodsi3.o:     iAPX 386 COFF object file not stripped - version 30821

So, it seems that coff and elf are mixed in all versions of libgcc.a!

...
> There are indeed a number of issues.   Until they're addressed correctly,
> perhaps we should just stick a "--enable-shared is not supported on this
> target" flag on it.

I guess that in the meanwhile a last resource fully working 
`configure' file in libstdc++ whould be helpfull.

> > Also, `make check' fails in all g++ tests! It suceed if I correctly
> > set LD_LIBRARY_PATH to `pwd`/libraries/libstdc++. The -L is setup, but
> > not LD_LIBRARY_PATH. SCO `ld' don't have a `-rpath' option.
> 
> It passes almost all of the tests without all this hackery.   To get a

*Not* whith a libstdc++.so.2.8.0! `make check' links with
-L libraries/libstdc++. If a .so is found, it is used; without
LD_LIBRARY_PATH, it miss it. This problem is addresses in the
makefile of libstdc++; for target check:, LD_LIBRARY_PATH is setup.

> You've also just discovered more reasons why a 'make bootstrap' really
> is necessary.   The build knows that egcs defaults to ELF, so it doesn't
> bother specifying the flags.  (And If it did, a bootstrap would fail

No, the files I reported are build *only once* at stage1 using the
host cc, without any options other that  CCLIBFLAGS, which is
empty. The mixing of elf and coff comes from here. At stage 1,
those files are built using the default cc (with default /etc/default/cc
options, can be elf or coff!), than, at stage n (n>1), bootstrap
builds the other files as elf.

> becuase '-melf' would choke /bin/cc.)   So you're going to get a
> hodgepodge of ELF and COFF in your libraries.

I already have, as I demonstrated. The solution is to set CCLIBFLAGS
to -belf, CC="cc -belf" to build a elf system, consistent with
bootstrap building elf files at stages n>1.

> Alternately, bootstrap EGCS once, do a 'make install' on it, then let
> configure use it.

and continue using `make bootstrap'?

> 
> Welcome to the sandpit...
> 
> RJL

Thanks for the welcome, :(

Thanks,
Joao

-- 
Joao Cardoso			|	e-mail: jcardoso@inescn.pt
INESC, R. Jose Falcao 110	|	tel:	+ 351 2 2094345
4000 PORTO, PORTUGAL		|	fax:	+ 351 2 2008487

Re: multilib and shared libs problems in sco-3.2v5.0.4

[Craig Burley]

>> Why isn't a shared libf2c build?
>
>The fortran crowd knows that libf2c isn't multilibbed.    It just hasn't
>floated to the top of anybody's todo list.   Patches would surely be 
>welcomed.

We're about to start making a bunch of changes (mostly cleaning up)
to the g77 and libf2c build procedures.  So if anyone wants to
contribute patches to either multilib libf2c or share it, it
might be worth waiting a couple of weeks or so until that job
is done, or at least making sure your patches or pretty simple and
don't try to be too clever working around the current weird cruft
in those procedures (so we can more easily see what is necessary
to preserve).

(These changes are largely implemented in g77 0.5.23, which is in
alpha testing right now and is based on gcc 2.8.1.  So making
the same kinds of changes in egcs' copy of g77 serves to keep
the two versions better synchronized, among other things.)

        tq vm, (burley)