A new version, that no longer tries to move all null parts to the end

of a segment. It also uses the "object" library to read and write ACK-
object files and libraries.

util/led/WRONG

@@ -1,56 +1,12 @@
 This file contains a summary of the bugs/features/inconsistencies
 Robbert and Ed found while making the linker usable for the 68000 and amoeba.
+I (Ceriel Jacobs) took the liberty of removing the ones that I fixed from
+this list.
 
-There is something wrong with the way the combination of
-assembler and linker handle bss.
-In the original (Duk's) the assembler translated .space and, worse, .align
-to a sequence of zero's. If this sequence was at the end of a segment
-within a module the assembler didn't put zero in the segment but sets
-os_flen to the amount of space initialized before the zero space
-and os_size to the segements size. (os_size - os_flen) is then the
-size of the space filled by zeroes.
-For the sake of clarity, let us call 0...os_flen-1 initialized space
-and os_flen..os_size-1 uninitialized space.
-Now the linker, it does a nasty trick. It gathers the uninitialized space
-of all modules within a segment and puts it consequtively at the end
-of the segment. I think that I understand the reason: This way you can keep
-your resultant a.out smaller and you don't need a special bss segment
-(a la unix). But it is incorrect, the net effect is that the .align's
-at the end of segments within a module do have the desired effect,
-the space thus allocated is removed to 'higher spheres' thereby
-leaving the first items of that segment in the inmediatly following
-modules at unaligned boundaries.
-What should be done is that the linker leaves the initialized and
-the unitialized code alone and regards the whole a a chunk that can be
-relocated. Only producing a difference of os_size and os_flen for
-the zeroes at the very end of the segment. Thereby collapsing all
-.space (and .align) commands into zero space only if they
-are in consequtive modules at the end of the segment, with modules
-NOT containing any initialized data.
-I already, ad-hoc, changed the code of the assembler to producing 'hard'
-zeroes when aligning. The trick could also be done for .space
-but is a bit harder here.
-The reason: .space is also used to allocate space in the BSS segment
-if that produced zeroes in the a.out file (0..bss_size) we would
-have a.out files that are far too large.
-This feature of the linker also caused weird effects for names that
-are defined as the very last in a section within a module, without
-any data (initialized or uninitialezed) after it.
-The names a regarded as pointing into the uninitialized space and
-thus relocated to the end of the section.
-The sequence
-	.sect .data
-begdata:
-	.sect ....
-in an head_em.s resulted in the relocation of begdata to the END
-of the .data segment.
 
 Another problem form the commons:
 1 - Local commons are not handled by led and not produced by as.
-    using .comm for unitialized data is not correct because (from C)
-    two uninitialized static declarations for the same name in
-    different modules will be handled as external commons and thus
-    be overlayed.
+    Must, and will be handled by as.
 2 - The commons are allocated at the very end of the first pass, after the
     initialezed data has been allocated in the segments. The order on which
     the commons are allocated seems to be random. That way it is impossible
@@ -67,6 +23,3 @@ replacing/adding/deleting modules is likely to produce libraries
 with incorrect ranlib entries.
 The major troublemaker seems to be the extra padding byte at the end
 of odd sized modules.
-
-Led should return a non-zero value when it has found Undefined symbols
-or has another reason for not being able to produce a correct output file.