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

[Joao Cardoso <jcardoso at inescn dot pt>]

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
*** libstdc++/configure.in-	Sat May  2 04:15:14 1998
--- libstdc++/configure.in	Sat May  2 04:15:27 1998
***************
*** 52,57 ****
--- 52,58 ----
      *-*-solaris*)	frags="${frags} sol2shm.ml" ;;
      *-*-sunos4*)	frags="${frags} sunos4.ml" ;;
      *-*-aix*)		frags="${frags} aix.ml" ;;
+ 	*-*-sco3.2v5*)	frags="${frags} sco5.ml" ;;
    esac
  fi
  
*** libstdc++/Makefile.in-	Sat May  2 06:16:19 1998
--- libstdc++/Makefile.in	Sat May  2 17:26:39 1998
***************
*** 88,94 ****
  	$(RANLIB) $(ARLIB)
  
  $(SHLIB): piclist
! 	$(CC) $(LIBCXXFLAGS) $(SHFLAGS) -shared -o $(SHLIB) `cat piclist` $(SHDEPS)
  
  $(SHARLIB): $(SHLIB)
  	-rm -f t$(SHARLIB)
--- 88,97 ----
  	$(RANLIB) $(ARLIB)
  
  $(SHLIB): piclist
! 	tt=`pwd`; ttt=`dirname $$tt`; tttt=`basename $${ttt}`; \
! 	if test ! $${tttt} = "coff"; then \
! 		$(CC) $(LIBCXXFLAGS) $(SHFLAGS) -o $(SHLIB) `cat piclist` $(SHDEPS); \
! 	fi
  
  $(SHARLIB): $(SHLIB)
  	-rm -f t$(SHARLIB)
*** config-ml.in-	Sat May  2 04:14:20 1998
--- config-ml.in	Sat May  2 04:14:30 1998
***************
*** 403,413 ****
--- 403,419 ----
  	    else \
  	      if [ -d ../$${dir}/$${lib} ]; then \
  		flags=`echo $$i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
+ 		if [ "$${flags}" = " -mcoff" ]; then \
+ 			picflag=""; \
+ 		else \
+ 			picflag="$(PICFLAG)"; \
+ 		fi; \
  		if (cd ../$${dir}/$${lib}; $(MAKE) $(FLAGS_TO_PASS) \
  				CFLAGS="$(CFLAGS) $${flags}" \
  				CXXFLAGS="$(CXXFLAGS) $${flags}" \
  				LIBCFLAGS="$(LIBCFLAGS) $${flags}" \
  				LIBCXXFLAGS="$(LIBCXXFLAGS) $${flags}" \
+ 				PICFLAG="$${picflag}" \
  				$(DO)); then \
  		  true; \
  		else \
*** libstdc++/config/sco5.ml-	Sun May  3 11:05:51 1998
--- libstdc++/config/sco5.ml	Sat May  2 15:19:54 1998
***************
*** 0 ****
--- 1,8 ----
+ # Elf without shared libm -- we have to link with the archive library, even
+ # for programs that don't use complex.
+ 
+ LIBS    = $(ARLIB) $(SHLIB) $(SHLINK)
+ SHFLAGS = -G -h $(SHLIB)
+ DEPLIBS = ../$(SHLIB)
+ LDLIBS  = -L.. -lstdc++ -lm
+ MLDLIBS = -L.. -lstdc++ -lm