[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: |
19 Feb 2004 23:07:43 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Hi Mike!
"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?
>
> Woops. Apologies are due here as it does in fact work (almost).
>
> Changes are needed to filter the first/lastfile objects from the objects
> collected in the "o" directory. I accidentally mixed those changes with
> your changes and worse still with some earlier ones of mine and blew your
> good work away.
>
> Then while very quickly looking at the Makefile to see why it hadn't worked,
> I saw the letters LD_LIBS_PRE and assumed that you were making pre and post
> archives rather than using the object files.
>
> Here is the needed diff:
>
> -------------------------------------------------------------------
> Enter passphrase for key '/home/miketh/.ssh/id_dsa':
> Index: unixport/makefile
> ===================================================================
> RCS file: /cvsroot/gcl/gcl/unixport/makefile,v
> retrieving revision 1.42.2.1.2.1.2.9
> diff -r1.42.2.1.2.1.2.9 makefile
> 45c45
> < OOBJS:=$(shell j=$$(ar t $(ODIR)/gcllib.a) ; for i in $$(ls -1
> $(ODIR)/*.o) ;
> do if ! echo $$j |grep $$(basename $$i) >/dev/null 2>&1 ; then echo $$i ; fi
> ; d
> one)
> ---
> > OOBJS:=$(shell j=$$(ar t $(ODIR)/gcllib.a) ; for i in $$(ls -1
> $(ODIR)/*.o) ;
> do if ! echo $$j |grep $$(basename $$i) >/dev/null 2>&1 ; then echo $$i |
> grep -
> v firstfile | grep -v lastfile; fi ; done)
>
> -------------------------------------------------------------------
>
OK, I just did something similar. Please test.
> | >
> | > | 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:
> | >
>
> Looking into this it turns out that the problem is simply that it needs a
> Windows conditionalised ".exe" extension to be deleted by delete-file:
>
> >(make-pathname :name "raw_foo" :directory '(:current) #+winnt :type #+winnt
> "exe")
>
> #p"./raw_foo.exe"
>
> This is not needed fot compiler output and system() calls as the compiler
> and the OS know what to do with executables, but it is needed for calls to
> delete-file which is quite rightly literal about it's argument.
>
OK, I think I've put in changes now that should let compiler::link
work on mingw. Please test. Note that the firstfile and lastfile
modules are shipped out in make install.
Take care,
>
> |
> | 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.
>
> Apart from the delete-file suggestion above this seems fine to me, but I
> have to say that I'm still learning CL and especially the pathname related
> functionality. (Ironic under the circumstances.)
>
> Cheers
>
> Mike Thomas.
>
>
>
>
> _______________________________________________
> 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/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, 2004/02/18
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/18
- Re: [Gcl-devel] ANSI Windows: in-package failure,
Camm Maguire <=
- 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