[Top][All Lists]
[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
- Re: [Gcl-devel] ANSI Windows: in-package failure, (continued)
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/03
- Re: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/04
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/04
- Re: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/09
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/11
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/15
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/16
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/16
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/17
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/17
- Re: [Gcl-devel] ANSI Windows: in-package failure,
Camm Maguire <=
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/18
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/19
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/20
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/20
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/11
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/11
Re: [Gcl-devel] Window ansi crash debug output, Camm Maguire, 2004/02/02