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

[Mike Thomas]

Hi Camm.

| OK, thank you *very* much for looking into this, and please accept my
| apologies in the following -- it appears I was at least partially
| mistaken in that mingw and gnuwin95 appear to be the only ports using
| these files.

No apologies are ever needed Camm!  When I mentioned sweating I was alluding
to the fogged up glasses and sweat filled eyes while programming syndrome.
Two nights ago we had a twenty year record high _minimum_ temperature at
night of 26 degrees.  It's expected to reach 38 degrees C by Friday with
high humidity.  Ignore me when I whinge - everyone here is doing it at the
moment and it leaks into my email like an overflowing dirty linen basket
onto the floor in a house full of teenagers.

| It still makes sense to ship them in the libraries for
| compiler::link, but now the problem is at least not so severe.
|
| Given the above, would simply renaming the files as follows work for
| you?
|
| firstfile.c -> aafirstfile.c
| lastfile.c -> zzlastfile.c?

Although this option sounds attractive it only fixes the first problem - the
objects are still not linked in the same order as they appear in the
archive.

On this basis I'm going to either have to modify compiler-link, ignore the
problem or find a better method for determining the extremities of the
running executable BSS area.

Is there some convenient package to build for testing a modified
compiler::link - I've never used it before?  Is it necessary for the Windows
build of any particular client software - Axiom etc?

Cheers

Mike Thomas

|
| Take care,
|
| "Mike Thomas" <address@hidden> writes:
|
| > 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.
| >
| >
| >
| >
| >
|
| --
| Camm Maguire                                          address@hidden
| ==========================================================================
| "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
|
|
| _______________________________________________
| Gcl-devel mailing list
| address@hidden
| http://mail.gnu.org/mailman/listinfo/gcl-devel
|
|