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

[Gabriel Dos Reis]

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