[Top][All Lists]

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

Re: [Gcl-devel] Re: open-axiom builds on mingw32

From: Camm Maguire
Subject: Re: [Gcl-devel] Re: open-axiom builds on mingw32
Date: Tue, 02 Nov 2010 17:57:35 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings, and thanks!  Should be fixed now.  Please let me know if
problems persist.

Take care,

Gabriel Dos Reis <address@hidden> writes:

> On Mon, Nov 1, 2010 at 10:25 AM, Camm Maguire <address@hidden> wrote:
> Hi Camm,
>> Here is how the raw_gcl.exe pathname is determined, which is not
>> related to the *system-directory* setting.  In general, it should
>> produce the truename of the current directory:
> You are absolutely right.  However, it looks like something
> in GCL-2.6.8pre (CVS) is looking at the GCL's build directory
> (which -- at the moment -- must also be its source directory)
> when preparing to same image.
> With your instruction below, I was able to reproduce the issue,
> so it is not related to OpenAxiom and you can reproduce it without.
> [...]
>> I suspect your C compiler could not write the file.  It is possible
>> but less likely that the file could not be executed.
>> I would suggest:
>> 1) find your installed saved_gcl, and execute
>> 2) (si::use-fast-links nil)(trace system open 
>> compiler::link)(si::save-system "ff")
>> 3) mv ff saved_gcl
> Here is what I did:
>   1. make clean
>   2. update GCL-2.6.8pre source
>   3. ./configure
>   4. make
>   5. make install
>   6. make clean
>   7. change to a completely different, temporary directory
>   8. Follow instruction as you outline above
>       It should fail as reported earlier.
> Note that there is NO failure if you skip step 6, i.e. if you don't clean up
> the build directory.  That makes me suspect that something is looking
> at the build directory.
> Note 2: there was no trace output so I could not get an idea about
> what is going on.
>> Separately, a few items I've noticed if interested:
>> 1)  make clean does not appear to remove the binaries
> Thanks for the feedback on this.  I'll look into them.
>> 2)  CFLAGS and LDFLAGS are not propagated.  This makes testing, for
>> example, on machines with more than one abi very difficult.
>> E.g. typically one tests sparc64 on a sparc32 machine with export
>> CFLAGS=-m64; export LDFLAGS=-m64.  All code must be so
>> compiled for the linker to combine it.
> Hmm, we don't support multilib at the moment but there ought to be a way
> to test sparc64 on a sparc32 machines.   I suspect this relates to your
> previous report about cross-compiling?
> Thanks!
> -- Gaby

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]