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

[Mike Thomas]

Hi Camm.


| Greetings!  OK, Mike , I've just put in some changes which should
| solve your problem.  Please let me know if not.

Still no go I'm afraid.  They'll have to be objects rather than archives.


| You might also want
| to test (compiler::link nil "/tmp/foo") and then try executing
| /tmp/foo.

Mixed results here, the pathing is going wrong and I haven't time today to
track it down further, but an executable raw_foo is generated:

===============================================================
>(compiler::link nil "c:/foo")
'.' is not recognized as an internal or external command,
operable program or batch file.

Error in COMPILER::LINK [or a callee]: Cannot delete the file "raw_foo".

Fast links are on: do (use-fast-links nil) for debugging
Broken at DELETE-FILE.  Type :H for Help.
 1 (Abort) Return to top level.
dbl:>>(compiler::link nil "foo")
'.' is not recognized as an internal or external command,
operable program or batch file.

Error in DELETE-FILE [or a callee]: Caught fatal error [memory may be
damaged]

Fast links are on: do (use-fast-links nil) for debugging
Broken at CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER.
 1 (Abort) Return to debug level 1.
 2 Return to top level.
dbl:>>>
===============================================================
$ cd unixport/
$ ../raw_foo.exe ./
GCL (GNU Common Lisp)  April 1994  131072 pages
Building symbol table for c:/cvs/stable/gcl-2.6.1/raw_foo.exe ..
rsym_nt: c:/cvs/stable/gcl-2.6.1/raw_foo.exe rsym2376
loading ./../lsp/gcl_export.lsp
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_top.o
Initializing gcl_module.o
loading ./../lsp/gcl_autoload.lsp

>(by)
==========================================================

More about the rest later, but I believe I put in a fix for the
si::*system-directory* stuff about a month ago.

Cheers

Mike Thomas.


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