Greetings, and thanks! Should be fixed now. Please let me know if problems persist.
Take care, Gabriel Dos Reis <g...@integrable-solutions.net> writes: > On Mon, Nov 1, 2010 at 10:25 AM, Camm Maguire <c...@maguirefamily.org> 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 c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel