[comp.unix.sysv386] Building X386v1.1

grant@gouche.UUCP (Grant Munsey) (02/20/91)

I found the following pitfall while rebuilding Thomas Roell's X386 v1.1

Environment: gcc 1.39 and ISC v2.2

After hacking include files some I got everything to compile and work
without shared libs. When I tried to use shared libs I got the following
ld error whenever I tried to link anything with the shared libs:

ld fatal: cannot combine NOLOAD input sections with other input sections;
possibly caused by shared library address space overlap

After a few false starts I used 'dump -hv libX11_s.a' and found out
that gcc1.39 (at least the version I ported) makes .bss sections for
uninitialized global data. It seems that pcc on ISCv2.2 does not do this,
allocating room in .data instead.

Since Thomas did not have lines of the form:

/**/#address .bss 0xB0800000

in his libxxx.def files (used for building shared libs) two section entries,
one for .data and one for .bss, were being put into the shared lib.

The .data and .bss sections had the same starting address!
This was causing ld to barf as above.

The fix I made is to go through all the *.def files in .../lib/* and reorder
the .text/.data addresses, and add a .bss entry. As far as I could see, each
of these segments must start on a 4mb boundary.

This works but a simpler solution would be nice. Is there a flag in gcc 1.39
to force stuff into .data? Maybe something else I missed? 
-- 
Grant Munsey, Mainticore, Inc. (408) 733-3838
grant@gouche.portal.com  or  {uunet!opusys,decwrl!apple!portal}!gouche!grant

grant@gouche.UUCP (Grant Munsey) (02/21/91)

The message I put out about trouble compiling X386v1.1 shared libs using
gcc 1.39 was all wet. Somehow I didn't get one of configuration files
in the gcc source updated right so my copy of gcc was emitting .bss when
it should have been emitting .data. 
-- 
Grant Munsey, Mainticore, Inc. (408) 733-3838
grant@gouche.portal.com  or  {uunet!opusys,decwrl!apple!portal}!gouche!grant

darrylo@hpnmdla.HP.COM (Darryl Okahata) (02/22/91)

In comp.unix.sysv386, grant@gouche.UUCP (Grant Munsey) writes:

> After a few false starts I used 'dump -hv libX11_s.a' and found out
> that gcc1.39 (at least the version I ported) makes .bss sections for
> uninitialized global data. It seems that pcc on ISCv2.2 does not do this,
> allocating room in .data instead.

      You're *NOT* using gcc 1.39.  This is a bug in 1.38 that was fixed
in 1.39.  I know because I had the exact same problem with 1.38 and
fixed it by going to 1.39 (I looked at the source and found that 1.39
had that bug fixed).

     -- Darryl Okahata
	UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo
	Internet: darrylo%hpnmd@relay.hp.com

pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/25/91)

On 21 Feb 91 08:49:12 GMT, roell@informatik.tu-muenchen.de (Thomas
Roell) said:

roell> 2. Now you should also mention, that you created a new
roell> data-section for each shared lib. This means at least 4kBytes
roell> additional memory requirement, plus some addtional memory for the
roell> region-table, and the mmu. Now consider an application like
roell> xterm. This one needs libX11, libXext, libXt, libXmu & libXaw.
roell> I.e an addtional memory-overhead of 20k (minimum !!!).  I think
roell> this is UNACCEPTABLE !

And here Thomas Roell gets blacklisted by the Imperial MITI DRAM
Service, and will never find a job with major Unix machine vendors :-).

Too bad for you, unless of course you clarify your statement and make it
obvious that you meant to say that an additional memory overhead of 20KB
is unacceptable because it is too small! :-).
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk