Hi Mathieu,
Mathieu Othacehe skribis:
> Even if guild has a "target" option allowing to cross-compile sources,
> autotools does not seem to have support for guile
> cross-compilation. For instance, passing "--host=aarch64-linux-gnu" to
> configure script doesn't set the "target" argument of guil
Hello!
To be able to add a cross-compilation option to guix-system (see
https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00062.html), we
need to cross-compile a bunch of guile libraries.
Even if guild has a "target" option allowing to cross-compile sources,
autotools does not seem to ha
Mike Gran writes:
> On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote:
>> Is there currently no way to get guile running under mingw-64bit? My plan
>> was to integrate guile in a project of mine which currently only builds
>> under 64bit.
>
> Well anything is possible, of course. Her
Christoph Buck writes:
> Currently i try to compile guile-2.2.4 under mingw64 bit.
Oh, interesting!
> I had some minor issues in the c source code which i managed to fix by
> applying some of the patches from
> https://github.com/mkeeter/guile-mingw. Namely
>
> 1) 0003-winsock-compat.mingw.patch
On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote:
> Mike Gran writes:
>
> > Hey Chris,
> >
> > This is one of two errors. One problem is that Guile makes assumptions
> > about the size of long vs the size of a pointer, as do some the
> > libraries on which Guile depends. In practi
Mike Gran writes:
> Hey Chris,
>
> This is one of two errors. One problem is that Guile makes assumptions
> about the size of long vs the size of a pointer, as do some the
> libraries on which Guile depends. In practice, your Guile needs to be
> compiled under MinGW 32-bit where sizeof(void *)
> From: Christoph Buck
> Date: Tue, 20 Nov 2018 15:31:25 +0100
>
> > ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> > In procedure bytevector-u64-set!: Value out of range: -149659645
> > make[2]: *** [Makefile:1931: ice-9/eval.go] Error 1
> > make[2]: Leaving directory '/home/Christo
On Tue, Nov 20, 2018 at 03:31:25PM +0100, Christoph Buck wrote:
> Hi!
>
> Currently i try to compile guile-2.2.4 under mingw64 bit. I had some
> minor issues in the c source code which i managed to fix by applying
> some of the patches from https://github.com/mkeeter/guile-mingw. Namely
[...]
>
Hi!
Currently i try to compile guile-2.2.4 under mingw64 bit. I had some
minor issues in the c source code which i managed to fix by applying
some of the patches from https://github.com/mkeeter/guile-mingw. Namely
1) 0003-winsock-compat.mingw.patch
2) 0004-start_child.mingw.patch
Now i am at th
Hi,
I have included the results of gdb debug. http://pastebin.com/AaWX2nhT
I don't have the strace results now but I will email here soon.
The actual error message and the patch used is as below.
The error message is here: http://pastebin.com/u1xsmKpg .
The patch is this: http://pastebin.com/
Hi Jiva,
I’ve reproduced the error message you posted below:
--8<---cut here---start->8---
i18n.c: In function 'str_upcase_l':
i18n.c:874:12: error: dereferencing pointer to incomplete type
i18n.c:874:12: error: dereferencing pointer to incomplete type
i18n.c:
Hi,
the target have strace. I will report the results here once I can use it.
I think one of the patch I was using might also have caused this issue.
So i have included the original error message here. If the patch was causing
this issue, It might be possible to solve this in some other way.
The e
On 08/17/2011 05:37 AM, Jiva bagale wrote:
the target machine doesn't have gdb and backtrace so it is even difficult to
find the problem.
Can anyone please help to find the possible issue?
then does the target have 'strace' ? maybe some help
--
Best Regards
Xiangfu Liu
http://www.openmobile
Hi,
I am trying to cross compile guile 2 on MIPS architecture using Openwrt.
My host machine and the target machine are little endian and both are 32 bit
architecture.
I managed to compile the binaries and .go files by defining GUILE_FOR_BUILD
as /usr/local/bin/guile.
But unfortunately, the guil
Hi!
Andy Wingo skribas:
> On Sun 29 May 2011 20:10, Andy Wingo writes:
>
>> On Fri 27 May 2011 16:51, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Sounds good, but you’d need additional data that maps triplets (well,
>>> $host_cpu) to low-level info such as endianness and word size, right?
>>
On Sun 29 May 2011 20:10, Andy Wingo writes:
> On Fri 27 May 2011 16:51, l...@gnu.org (Ludovic Courtès) writes:
>
>> Sounds good, but you’d need additional data that maps triplets (well,
>> $host_cpu) to low-level info such as endianness and word size, right?
>
> Yes, which caused me a bit of ago
Hi :)
On Fri 27 May 2011 16:51, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribas:
>
>> After having read "Using System Type" again in the autoconf manual, I am
>> convinced again that the right thing to do is to add a %target-type
>> fluid or mutable parameter, defaulting to the %host
Hello!
Andy Wingo skribas:
> After having read "Using System Type" again in the autoconf manual, I am
> convinced again that the right thing to do is to add a %target-type
> fluid or mutable parameter, defaulting to the %host-type. We select how
> to compile for the target by making decisions b
So!
On Mon 21 Mar 2011 21:42, Andy Wingo writes:
> On Mon 21 Mar 2011 20:58, l...@gnu.org (Ludovic Courtès) writes:
>
>> At some point there will have to be a triplet → arch → endianness
>> conversion.
>
> Indeed.
>
>> I’d rather have that conversion occur as close to the UI as
>> possible—i.e.
On Mon 21 Mar 2011 20:58, l...@gnu.org (Ludovic Courtès) writes:
> At some point there will have to be a triplet → arch → endianness
> conversion.
Indeed.
> I’d rather have that conversion occur as close to the UI as
> possible—i.e., close to ‘scripts/compile.scm’—rather than deep down in
> (sy
Hello!
Andy Wingo writes:
> On Sun 20 Mar 2011 22:31, l...@gnu.org (Ludovic Courtès) writes:
[...]
>> Thus ‘%target-type’ would be inappropriate IMO because the target could
>> be chosen at run-time and it could be anything.
>>
>> ‘guile-tools compile --target=TRIPLET’ would be fine with me.
>
On Sun 20 Mar 2011 22:31, l...@gnu.org (Ludovic Courtès) writes:
> What I meant to say here, is that via a couple of knobs akin to
> ‘current-target-endianness’, you could actually cross-build for any
> target.
Yes, provided you have the compiler of course.
> Thus ‘%target-type’ would be inappro
Hi!
Andy Wingo writes:
> On Sun 20 Mar 2011 14:50, l...@gnu.org (Ludovic Courtès) writes:
[...]
>> However, I don’t think defining ‘%target-type’ would make sense
>> since:
>>
>> 1. Of the GNU triplet, only the $target_arch matters for bytecode;
>>
>> 2. You can really choose at run-time w
Hi :)
On Sun 20 Mar 2011 14:50, l...@gnu.org (Ludovic Courtès) writes:
> There’s already ‘%host-type’.
Ah, cool.
> However, I don’t think defining ‘%target-type’ would make sense
> since:
>
> 1. Of the GNU triplet, only the $target_arch matters for bytecode;
>
> 2. You can really choose at
Hello!
Andy Wingo writes:
> It's true that a simple command-line argument and fluid could work, but
> the situation will get more complicated, so we will need some part of
> Guile to define the host and target triplets. That's the questions I
> was really asking: where in Guile to define those?
On Fri 18 Mar 2011 11:17, l...@gnu.org (Ludovic Courtès) writes:
> I would add a ‘current-bytecode-endianness’ fluid in (language assembly
> compile-bytecode). The ‘compile’ procedure would have an optional
> ‘endianness’ parameter, which would set this fluid. And ‘guile-tools
> compile’ would h
Hello Andy!
Andy Wingo writes:
> On Sun 06 Mar 2011 23:12, l...@gnu.org (Ludovic Courtès) writes:
>
>> Neil Jerram writes:
>>
>>> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
>>> mostly of the part of the build that compiles all the installed modules.
>>
>> Guile 2.0 can
On Sun 06 Mar 2011 23:12, l...@gnu.org (Ludovic Courtès) writes:
> Neil Jerram writes:
>
>> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
>> mostly of the part of the build that compiles all the installed modules.
>
> Guile 2.0 can only be cross-compiled when the endianness
Neil Jerram schreef op za 05-03-2011 om 19:47 [+]:
> In principle, how should Guile 2.0 be cross-compiled?
We're using GUB -- http://lilypond.org/gub and are
sucessfully cross-building guile-2.0. You may want
to look at some patches
https://github.com/janneke/gub/tree/guile-2.0/patches
Hi,
On Sun 06 Mar 2011 12:03, Neil Jerram writes:
> What architectural dependencies are there in the .go format?
Only endianness and word size.
Of course a macro could check something about the system at
expansion-time, for example a value in a header; and there are things
like the mapping of
Hi Neil,
Neil Jerram writes:
> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
> mostly of the part of the build that compiles all the installed modules.
Guile 2.0 can only be cross-compiled when the endianness and word size
of the host and target match (because the bytecode
ed anything, so I really don't know.
>
> Ideally we could make a cross-compiling Guile that executed on the host,
> but produced .go files for the target.
>
> Humm. Does that mean that for cross-compile builds, that we should
> not add the $builddir to the LOAD_COMPILED_PATH?
On Sat 05 Mar 2011 20:47, Neil Jerram writes:
> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
> mostly of the part of the build that compiles all the installed
> modules.
I have never cross-compiled anything, so I really don't know.
Ideally we could mak
In principle, how should Guile 2.0 be cross-compiled? I'm thinking
mostly of the part of the build that compiles all the installed modules.
I think target emulation is needed, using QEMU, and in particular that
it wouldn't work to set GUILE_FOR_BUILD to a build-system-native guile,
because that w
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Now that we're busy dropping cruft, it would be really nice if we could
> libtool too. (major sigh).
But we don't want to drop supported platforms, so we can't drop
Libtool. And Libtool is friendly, isn't it? :-)
Ludo'.
Ludovic Courtès escreveu:
> Hello,
>
> "Han-Wen Nienhuys" <[EMAIL PROTECTED]> writes:
>
>> autoreconf: running: aclocal --force
>> autoreconf: configure.in: not using Libtool
>> autoreconf: running: /home/hanwen/usr/pkg/ac/bin/autoconf --force
>> configure.in:20: error: possibly undefined macro:
Ludovic Courtès escreveu:
>
> Looks like the machine is missing Libtool or at least that its M4 macros
> cannot be found. You need Libtool 1.5.x, *not* Libtool 2.2.
>
>> How do I get GUILE to actually compile now?
>
> How did you get it to compile last week? :-)
I used my 32 bit laptop, but
Hello,
"Han-Wen Nienhuys" <[EMAIL PROTECTED]> writes:
> autoreconf: running: aclocal --force
> autoreconf: configure.in: not using Libtool
> autoreconf: running: /home/hanwen/usr/pkg/ac/bin/autoconf --force
> configure.in:20: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
> If this t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Han-Wen Nienhuys wrote:
> Also, can someone tip me off how I create 64 bit binary on a mixed
> 32/64 machine? I assume the default
> will generate a 32 bit binary.
Actually I would think the default is to generate 64-bit code, but you can pass
gcc t
Hi,
I'm trying to compile GUILE on a x86_64 machine, to figure out the GC problems
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force -I guile-config -I m4
configure.in:815: warning: macro `AM_GNU_GETTEXT' not found in library
autor
40 matches
Mail list logo
