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