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

[Camm Maguire]

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