RE: [Gcl-devel] ANSI Windows: in-package failure

[Mike Thomas]

Hi Camm.

Thanks again for your help.  I hope one day we can all meet in person so
that we can look back on 2.6.2 and laugh about it!

| OK, unfortunately, I'm going to have to revert your patch to
| unixport/makefile.  We'll have to work out something else I fear, as I
| need the firstfile/lastfile in the libraries so that compiler::link
| will work.  Can you figure out which ar options on your system will
| link the library's objects in the right order?

There are two issues here.

The first is that for me, the Makefile target instructions do not provide
the member object files in the order implied by the dependency list.   I
suppose there is an ordering difference in the way "filter" or $^ works.

The second is that even when I rearrange the archive members into the order
I believe that you are trying to achieve, they are apparently reordered by
the linker (as opposed to the archiver).  My guess is that this is probably
being caused by a need to produce C libraries compatible with MSVC++.

As far as the first problem is concerned, here is the ar argument line with
excess files elided:

ar rs libansi_gcl.a ../o/firstfile.o ../o/alloc.o \

.... o directory alphabetical order objects here ... \

../o/iteration.o ../o/lastfile.o ../o/let.o  \  ; lastfile.o in wrong place?

.... o directory alphabetical order objects here ... \
.... lsp directory alphabetical order objects here ... \
.... cmpnew directory alphabetical order objects here ... \
.... pcl directory alphabetical order objects here ... \
.... clcs directory alphabetical order objects here ... \

../clcs/clcs_top_patches.o sys_ansi_gcl.o gmp/gmp3_assert.o \ ;
sys_ansi_gcl.o
.... gmp directory alphabetical order objects here ...

Doing

        ar ma sys_ansi_gcl.o $@ $(LAST_FILE)

sets the order in the archive correctly as reported by "ar t", but still
lastfile.o is linked in too early when the raw exe is built.  I've also
tried moving the file to the end: ar m $@ $(LAST_FILE).  Also both those
methods without ranlib and without the "s" modifier to "ar".  Also
hardwiring the positions of the files!

|  That would be the most
| compatible solution.  Next would be adding -u options to the link
| command line for the raw image to specify the link order in the
| presence of conflicts, (i.e. modules explicitly named on the command
| line vs. modules in the libraries), much as we do for gmp3/mul_n.o
| now.

I assume you mean this:

============================================================================
==
-u symbol
    Pretend the symbol symbol is undefined, to force linking of library
modules to define it. You can use -u multiple times with different symbols
to force loading of additional library modules.
============================================================================
==

An hour of sweating over the make and log files on the weekend (plus some
substantially more pleasant air-conditioned time this morning) left me none
the wiser on what the makefile actually does with that file that
involves -u.

As far as I can see, gmp3/mpn/mul_n.o is copied to
unixport/gmp/gmp3_mpn_mul_n.o and then added to the lib*_gcl.a archives
which are used to link the raw*_gcl.exe executables.

| Lastly, we could make use of definitions in mingw.defs to give
| mingw specific usage, but this would disable compiler::link on mingw.

Unless, perhaps, we change compiler::link to explicit pass first/lastfile.o
in the appropriate positions, which also means installing and distributing
those two files separately from the archives.

Linking those two objects directly at the point of making the executables is
the only way to go that I have so far discovered for MinGW32.

Cheers

Mike Thomas.