On Thu, Jul 10, 2008 at 5:02 AM, Faré <fahree@...> wrote:
> 1- assuming you have 32-bit libraries installed, you can compile
> simple things on a 64-bit system with CC="gcc -m32" or CFLAGS="-m32
> -O2" or something like that.
Unfortunately it doesn't look like my system have 32-bit libraries
installed because it couldn't find /usr/include/gnu/stubs-32.h :-(
> 2- you can trivially install a 32-bit debian (or redhat, etc.) system
> on your 64-bit machine and use it using chroot, dchroot, etc.
Actually, I just remembered that UCSD runs its Linux servers on i386
Redhat Linux. I had to install things in unusual places (since I don't
have access to the normal locations), but I managed to compile with
x86 EBX threads. That said, the run-tests.sh seem to fail when
attempting to test thread support, so obviously not everything works
smoothly... but hopefully Alastair Bridgewater's updated patch should
fix that. (Making this test obsolete, but at least now I have a
procedure for testing on Linux/x86.)
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> I contend we are both atheists, I just believe in one fewer god than you do.
> When you understand why you dismiss all the other possible gods, you will
> understand why I dismiss yours. -- Stephen F Roberts
> 2008/7/10 Elliott Slaughter <elliottslaughter@...>:
> > Thanks for all the help :-)
> > On Wed, Jul 9, 2008 at 6:57 AM, Christophe Rhodes <csr21@...> wrote:
> >> "Elliott Slaughter" <elliottslaughter@...> writes:
> >>> (And I'm not sure how to do a cross-compile for just plain x86.)
> >> If you're lucky, then "SBCL_ARCH=x86 ./make.sh" will do it.
> > Unfortunately without 32-bit gcc this caused many warnings and finally
> > a fatal error in the assembler.
> >> (Your system might well need a bunch of clever development tools,
> >> but I think it can be made to work; you might need to alter paths
> >> so that gcc points to the 32-bit one, etc.)
> > Would you expect an x86_64 Linux system to come with both 64 and
> > 32-bit copies of gcc by default? Looking in /usr/bin/ I can see
> > x86_64-linux-gnu-gcc but no plain x86 version. I could probably
> > compile a cross compiler, but I don't know exactly how much effort
> > would be involved in making that work.
> >> Otherwise, install an x86 somewhere, virtualized or physical, or get
> >> remote access to one.
> > I don't know if I have access to any x86 Linux machines.... I *do*
> > have two free hard drives on my machine so I might be able to run
> > plain x86 on top of my x86_64 machine. (Correct me if I'm not thinking
> > straight.) Anyway, I can't try this until tomorrow after I get
> > broadband internet installed, because a multiple hundred MB download
> > is simply impossible on 56 Kb dial-up.
> >>> On win32, compilation failed (not unexpectedly). I resolved several C
> >>> compilation errors, which got me past genesis, but upon attempting to
> >>> load cold-sbcl.core into the new system, something broke and dropped
> >>> the system into ldb (see below). In case more context is desirable, I
> >>> have uploaded the entire session to
> >>> http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z .
> >>> //doing warm init - compilation phase
> >>> This is SBCL 126.96.36.199, an implementation of ANSI Common Lisp.
> >>> More information about SBCL is available at <http://www.sbcl.org/>.
> >>> SBCL is free software, provided as is, with absolutely no warranty.
> >>> It is mostly in the public domain; some portions are provided under
> >>> BSD-style licenses. See the CREDITS and COPYING files in the
> >>> distribution for more information.
> >>> This is experimental prerelease support for the Windows platform: use
> >>> at your own risk. "Your Kitten of Death awaits!"
> >>> *
> >>> 10
> >>> *
> >>> 5
> >>> *
> >>> T
> >>> *
> >>> *COMPILE-FILES-P*
> >> OK, so you're running Lisp code successfully, all the way up to warm
> >> init of the system; on the other hand, you manage to corrupt the image
> >> before or shortly afterwards, such that you don't get a nice friendly
> >> debugger when something goes wrong. Allocation can't be completely
> >> off, because there's a huge amount of allocation in cold-init. What
> >> about GC? What happens if you disable the garbage collector (or
> >> rather, don't re-enable it; look for (gc-on) and (gc :full t) in
> >> src/code/cold-init.lisp)?
> > I commented out both (gc-on) and (gc :full t) and still observed
> > exactly the same crash.
> >> One other thing to do is to review the entire patch, carefully, line
> >> by line, until you're sure you understand how everything there
> >> interacts.
> > Hmm... I agree that my understanding of the code is a bit sketchy
> > right now and could use some strong reinforcement. But I am not sure
> > reading the patch line by line is the best method... it is 78 KB
> > (about 2000 lines) after all.
> >> Another might be to make sure that the patch as applied to
> >> the version of SBCL it was "designed" for works as it used to.
> > Yes, the old patch, when applied to 188.8.131.52 (incidentally, branch
> > ebx-1 in my repo), compiles and runs just fine. (You can even start
> > threads, although it is probably not a good idea to run multiple
> > threads, or generate any garbage.) So the problems I am observing are
> > probably either some conflict with changes introduced after 184.108.40.206,
> > or something I managed to mess up myself.
> > Any other suggestions would be greatly appreciated.
> > --
> > Elliott Slaughter
> > "Any road followed precisely to its end leads precisely nowhere." -
> > Frank Herbert
> > -------------------------------------------------------------------------
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> > _______________________________________________
> > Sbcl-devel mailing list
> > Sbcl-devel@...
> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
"Any road followed precisely to its end leads precisely nowhere." -