Add Native Code Pointer to Objcode
Hello all, The attached patch compresses the objcode representation a bit, then adds space for a native code pointer. The whole thing ends up being four words, as it is now. The patch depends on this idea, so please let me know if it is wrong: the current objcode representation uses its last two words to store the object the objcode came from - a bytevector if the objcode is from a bytevector, a file if it is from a file, etc. But each objcode can only be from one thing, so in fact we only need to use one word to store that. (Currently, one of the last two words will always be 0.) The interesting changes are probably all in libguile/objcodes.c and libguile/objcodes.h. I also changed all of the files that contained static objcode, but those are pretty repetitive changes. Noah 0001-Space-for-Native-Code.patch Description: Binary data
Re: How Do I Debug a Boot Error?
Hello, Thank you both! As it turned out, this was the issue that was caused by the update to Gnulib, so the error is currently gone. However, I realize that in general it would be great to have better error messages in situations like this. I might be able to re-break my Guile some time and try to make it give better messages. Noah On Mon, Dec 20, 2010 at 5:52 PM, Andy Wingo wrote: > Hi Noah, > > On Fri 17 Dec 2010 20:33, Noah Lavine writes: > >> ;;; compiling >> /Users/noah/Desktop/guile/guile/module/language/objcode/spec.scm >> guile: uncaught throw to wrong-type-arg: (#f Wrong type (expecting >> ~A): ~S (exact integer (#t # #> 1037f8880> #)) ((#t #> 1037f88a0> # #))) >> >> How should I debug such a thing? > > Well, it should not be so bad -- I mean this is really terrible > feedback, and no one should see that. > > But that said, run it as meta/gdb-uninstalled-guile, break on > scm_ithrow, and then call scm_backtrace from with the breakpoint > handler. > > Be on the lookout for a general solution, too; this error message is > terrible. > > Andy > -- > http://wingolog.org/ >
Re: How Do I Debug a Boot Error?
Hi Noah, On Fri 17 Dec 2010 20:33, Noah Lavine writes: > ;;; compiling /Users/noah/Desktop/guile/guile/module/language/objcode/spec.scm > guile: uncaught throw to wrong-type-arg: (#f Wrong type (expecting > ~A): ~S (exact integer (#t # # 1037f8880> #)) ((#t # 1037f88a0> # #))) > > How should I debug such a thing? Well, it should not be so bad -- I mean this is really terrible feedback, and no one should see that. But that said, run it as meta/gdb-uninstalled-guile, break on scm_ithrow, and then call scm_backtrace from with the breakpoint handler. Be on the lookout for a general solution, too; this error message is terrible. Andy -- http://wingolog.org/
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 12/20/2010 03:09 PM, Bruce Korb wrote: On 12/19/10 20:40, Noah Lavine wrote: Hello, I am not at all an expert on guile-config, but I will help if I can. Thank you to all who responded. Usually if you have 64-bit libs in lib64, you have to pass --libdir explicitly. We've now concluded that that is, indeed, the answer to the original question. The fallout question: How much understanding of the machinery should be expected of the hapless project builder? Nelson has been doing this stuff for quite a while and has reasonably good understanding of the process. From that understanding, he made the assumption that a standard 64 bit "Red Hat Enterprise Linux Server release 5.5 (Tikanga)" installation would be compatible with installing Guile via ./configure&& make&& sudo make install and not wind up with a frumitzed `guile-config link` output. The assumption was incorrect and we now know that. Correct, this assumption is incorrect. (With my Fedora Packaging Committee member hat on) In Fedora and RHEL, users are supposed to pass --libdir=/usr/lib64 to configure on x86_64 and --libdir=/usr/lib to configure on i386. Analogous conventions apply to other multilib'ed architectures. Ralf
Re: How does one specify linking to 64 bit libraries when there is a choice?
Hello, When a work subscription to libtool and a home subscription to guile-devel collide... On Mon 20 Dec 2010 05:40, Noah Lavine writes: > I found the file that pkg-config will be using to give you this > information. It is meta/guile-.pc in my Guile source > tree. Furthermore, I think it's safe to assume that it is generated > from meta/guile-.pc.in. I think with 1.8, which is what Nelson is trying to build, it's still a fairly thick thing. >> On 12/17/10 11:57, Nelson H. F. Beebe wrote: >>> /usr/local/bin/guile-config still reported -L/usr/local/lib. Usually if you have 64-bit libs in lib64, you have to pass --libdir explicitly. So you would configure guile using: ./configure --prefix=/usr/local --libdir=/usr/local/lib64 If you still get /usr/local/lib coming out in guile's configure, you may have a libtool-related issue, but I doubt it. Cheers, ANdy
Re: How does one specify linking to 64 bit libraries when there is a choice?
Hi Bruce, Sorry you and others have had to suffer through this. On Mon 20 Dec 2010 15:09, Bruce Korb writes: > How much understanding of the machinery should be expected > of the hapless project builder? I'm not sure, but: > Nelson has been doing this stuff for quite a while and has > reasonably good understanding of the process. From that > understanding, he made the assumption that a standard 64 bit > "Red Hat Enterprise Linux Server release 5.5 (Tikanga)" > installation would be compatible with installing Guile via >./configure && make && sudo make install This is incorrect, for RHEL and other systems which place 64-bit libs in $prefix/lib64. You will find hacks to set --libdir in almost all packaging scripts. > Perhaps we can strive to make the assumption correct > in the future? This idea is attractive, if it can be done. But this is more an autoconf issue (setting $libdir) than a libtool issue, and it's not a Guile issue at all :) Cheers, Andy
Re: How Do I Debug a Boot Error?
Hi Noah, Noah Lavine writes: > I've managed to get Guile to give me this error when it starts up: > > ;;; compiling /Users/noah/Desktop/guile/guile/module/language/objcode/spec.scm > guile: uncaught throw to wrong-type-arg: (#f Wrong type (expecting > ~A): ~S (exact integer (#t # # 1037f8880> #)) ((#t # 1037f88a0> # #))) What does “make -C module” do? What about rebuilding all the ‘.go’ files? I would first try to get back to a working state, will all .go files compiled, and then find out which change triggered the faulty behavior. FWIW... Thanks, Ludo’.
Re: Request for Latest Gnulib
Hello, Noah Lavine writes: > All of which is a long way of saying, please merge the latest version > of Gnulib so I will be able to build Guile again. Done! Ludo’.
Re: How does one specify linking to 64 bit libraries when there is a choice?
* Ralf Wildenhues wrote on Mon, Dec 20, 2010 at 08:20:25PM CET: > The other crucial part is that libtool doesn't get the > sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings > right on several distros, introducing such wrong directories itself (not > to speak of cross setups). There have been several proposed patches to > address this, e.g. > http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625 > http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931 > but I have yet to see one that solves it. ESENDTOOSOON, sorry. At least with current Libtool you can override wrong settings with the lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec cache variables.
Re: How does one specify linking to 64 bit libraries when there is a choice?
* Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET:
> How much understanding of the machinery should be expected
> of the hapless project builder?
I've skimmed most of the conversation in this thread now.
The crucial part, I think, is *not* the --libdir setting. Distros
usually get that consistent between their packages, and users should not
be using any of /usr/lib{,32,64} but rather something below /usr/local.
One crucial part is that libtool gets confused whenever it has
directories with the wrong ABI in the search path (unlike ld or ld.so,
both are in some cases smart enough to skip wrong ABI), which means that
either no instance of the build system machineries may introduce such
paths, or libtool needs to get smarter to ignore wrong ABI dirs.
The other crucial part is that libtool doesn't get the
sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
right on several distros, introducing such wrong directories itself (not
to speak of cross setups). There have been several proposed patches to
address this, e.g.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
but I have yet to see one that solves it.
Thanks,
Ralf
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 12/19/10 20:40, Noah Lavine wrote: > Hello, > > I am not at all an expert on guile-config, but I will help if I can. Thank you to all who responded. > Usually if you have 64-bit libs in lib64, you have to pass --libdir > explicitly. We've now concluded that that is, indeed, the answer to the original question. The fallout question: How much understanding of the machinery should be expected of the hapless project builder? Nelson has been doing this stuff for quite a while and has reasonably good understanding of the process. From that understanding, he made the assumption that a standard 64 bit "Red Hat Enterprise Linux Server release 5.5 (Tikanga)" installation would be compatible with installing Guile via ./configure && make && sudo make install and not wind up with a frumitzed `guile-config link` output. The assumption was incorrect and we now know that. Perhaps we can strive to make the assumption correct in the future? Thank you! Regards, Bruce
Re: Nice quote from the cover of R2RS
Mark H Weaver writes: > Data and procedures and the values they amass, > Higher-order functions to combine and mix and match, > Objects with their local state, the messages they pass, > A property, a package, the control point for a catch-- > In the Lambda Order they are all first-class. > One Thing to name them all, One Thing to define them, > One Thing to place them in environments and bind them, > In the Lambda order they are all first-class. Thanks, I enjoyed that. I'd say the first half is more Auden (like the Night Mail) than Tolkien though. > I wonder if it might be included in the Guile manual for fun. For me, it's close but not quite there yet. The scansion doesn't really work, and for me that let's it down. But I imagine that could be fixed, if someone wants to have a go at it. Neil
