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

[Camm Maguire]

Greetings!  OK, Mike , I've just put in some changes which should
solve your problem.  Please let me know if not.  You might also want
to test (compiler::link nil "/tmp/foo") and then try executing
/tmp/foo.  This should also work post installation providing your
setting the si::*system-directory* variable to the correct new
location, as we've discussed previously.  It looks like we're just
awaiting a few macosx finalizations, and perhaps some bsd tests,
before releasing 2.6.2.  If you have a chance to chase down that
longjmp error and isolate it before the above is finished, we might be
able to squash that too.

Take care,

"Mike Thomas" <address@hidden> writes:

> 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
> |
> |
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah