Ticket #23 (new enhancement)
Opened 3 years ago
Extend handling of archive files
| Reported by: | debrouxl | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | Version 1.00 |
| Component: | toolchain-ar-tigcc | Version: | 0.96 |
| Keywords: | Cc: |
Description
ar-tigcc doesn't know how to *import* an archive file: it puts archive files verbatim as one file, without adding the contained symbols to the symbol table.
ar-tigcc -o foo.a bar.a [other object/archive files] (this is what tprbuilder calls on 'foo.tpr' containing 'Archive=1', Archive File bar.a and other files) yields an archive that doesn't work properly: everything contained in the embedded archive files is invisible.
ld-tigcc doesn't know how to *export* an archive file (that's logical, it's the duty of ar-tigcc): ld-tigcc -o archive3.a archive1.a archive2.a refuses to link an empty program.
This prevents from doing such truly advanced archive manipulations as creating an archive file from another archive file + several object files, without resorting to external tools like a full-blown ar binutil.
I did exactly this for a long time in ExtGraph?, but the recent addition of A68k files broke the compilation process: the m68k-coff-ar binaries in the repository don't handle AmigaOS files (which A68k generates), and both [A68k -> gas syntax translation] and [binutils recompilation] are pains...
I worked around this limitation of ar-tigcc (r77 of ExtGraph?) by compiling separately (as before) those files that have different compilation options, before including them as object files in a TPR.
An enhancement to ar-tigcc would be adding it the capability to import archive files, and recursively flatten them into a single output archive file.
