Hi Neil,
Neil Jerram wrote:
2008/11/11 Jon Wilson <[EMAIL PROTECTED]>:
Hi Neil,
Thanks for working on this. I'd favor the steady new features model, but I
would recommend periodically marking a release as one that will be supported
past the next release, similar to Ubuntu's LTS releases.
Why
On Tue, Nov 18, 2008 at 11:10:42PM +0100, Andy Wingo wrote:
> Hi Igor
>
> On Tue 18 Nov 2008 22:48, Igor Chudov <[EMAIL PROTECTED]> writes:
>
> > Any idea how I can cross compile and build a 32 bit version on a 64
> > bit platform Ubuntu Hardy?
>
> I haven't actually done this, but try:
>
> C
Hi Igor
On Tue 18 Nov 2008 22:48, Igor Chudov <[EMAIL PROTECTED]> writes:
> Any idea how I can cross compile and build a 32 bit version on a 64
> bit platform Ubuntu Hardy?
I haven't actually done this, but try:
CC='gcc -m32' ./configure
Also, as long as you're compiling from source, perhaps
Hello,
Boris Zbarsky <[EMAIL PROTECTED]> writes:
> That doesn't seem to have any effect. Interestingly, if I change the
> setitimer call but NOT the sigaction call I see the program terminate
> with an uncaught SIGPROF... So clearly the sigaction is having _some_
> effect. Just not that of cal
I am on a 64bit Ubuntu Hardy installation. I am trying to build Guile
1.8.3 but to build a 32 version thereof. (cross compile).
So I did
./configure --host=i386
but this seems to have no effect and builds a x86_64 version of guilt,
which is NOT what I want.
Any idea how I can cross compile
Ludovic Courtès wrote:
Maybe with `strace(1)' or similar?
Unfortunately, that just shows the pointer to the struct, not the
value in the struct itself
Under GNU/Linux it does the right thing. :-)
Ah, cool. I'll dig up my Linux machine at some point to double-check
this if I exhaust al
Hi,
Boris Zbarsky <[EMAIL PROTECTED]> writes:
> Ludovic Courtès wrote:
>> Maybe with `strace(1)' or similar?
>
> Unfortunately, that just shows the pointer to the struct, not the
> value in the struct itself
Under GNU/Linux it does the right thing. :-)
> I tried adding that call to code t
Hi,
Andy Wingo <[EMAIL PROTECTED]> writes:
> Beating a dead horse, 1.8.5 should be compatible with 1.8.3, via
> whatever mechanism. (The actual problem in this case was elsewhere.)
1.8.5 *is* compatible with 1.8.x.
> I am skeptical of pushing significant changes into stable branches. I
> really
Hi,
On Mon 17 Nov 2008 00:33, [EMAIL PROTECTED] (Ludovic Courtès) writes:
>> And I assume the actually loaded libguile was version 1.8.5? So there
>> should have been something in the library saying that it needed 1.8.3,
>> which would have caused the link to fail. Does the libtool scheme
>> co