gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Camm Maguire
Subject: Re: [Gcl-devel] ANSI Windows: in-package failure
Date: 18 Feb 2004 09:50:10 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Mike Thomas" <address@hidden> writes:

> 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.
> 

Does this mean you can't compile with the new makefiles?  To my
knowledge, I did put the objects on the link command line, and take
them out of the libs.  Can you post the build output if failing?

> 
> | 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:
> 

OK, I suppose this is why lisp has those pathname functions, which I
still don't know how to use very well.  I'm about to commit some
changes getting rid of ./ and ../ in favor of the following:

(defun mysub (str it new)
  (let ((x (search it str)))
    (unless x
      (return-from mysub str))
    (let ((y (+ (length it) (the fixnum x))))
      (declare (fixnum y))
      (concatenate (type-of str)
                   (subseq str 0 x)
                   new
                   (mysub (subseq str y) it new)))))

*ld-libs* ->       (let* ((par (namestring (make-pathname :directory 
'(:parent))))
                  (i (concatenate 'string " " par))
                  (j (concatenante 'string " " si::*system-directory* par)))
             (mysub *ld-libs* i j))


(format nil "./~a" raw) -> (format nil "~a" 
                (namestring (make-pathname :name raw :directory '(:current)))


Comments on how to do this nicely are most appreciated.

Take care,


> ===============================================================
> >(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
> |
> 
> 
> 
> 
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]