bug#13848: Statically linking guile-2.0.

[Jan Schukat <shookie@email.de>]

[-- Attachment #1: Type: text/plain, Size: 5199 bytes --]

On 03/09/2013 10:32 AM, Andy Wingo wrote:
> Hi,
>
> On Fri 01 Mar 2013 17:19, Jan Schukat<shookie@email.de>  writes:
>
>> But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not
>> sure how often it is tested by the developers.
> Approximately never, unfortunately.  However we have been improving it
> recently, and cross-compiling from GNU systems to MinGW is done
> occasionally.
>
> I will mostly address concerns about cross-compiling.  Note that you
> should really be using Guile from stable-2.0 git and the latest MinGW.
>
> The easiest way to do that is to install a Fedora 18 VM, because they
> package mingw very well and are closest to upstream.  I'm a Debian user
> and that's what I did, FWIW.  I haven't yet tried with Debian itself.
>
> Also I would mention that dynamic linking should work on Windows, if all
> your DLLs are in the same folder.  But I am ignorant and maybe that
> doesn't work.

Well, I really do my linux builds and most development on linux: that's 
the uname -a:

Linux solon 3.5.0-26-generic #40-Ubuntu SMP Tue Feb 26 19:59:36 UTC 2013 
i686 athlon i686 GNU/Linux

My windows builds I really do on windows7/mingw, the uname -a there:

MINGW32_NT-6.1 BIAS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys

I haven't even tried to do any of that guile building on OSX, and as I 
understand cross-compiling from Linux to OSX is more or less 
impossible/a nightmare (the VLC guys do it though I think), so I will do 
it on my old iMac too.

I really would like to do all 3 targets via cross compiles some day 
(especially since compilation on linux is the fastest by far), but for 
now I just want to get it to work and have something to build on.


>> Also, when you link statically and the symbol resolving works
>> differently, you have to go through some hoops to resolve boehm-gc
>> symbols, despite the preprocessor guards: That concerns
>> HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE,
>> HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile
>> there are statically defined fallbacks for the respective functions,
>> that cause linker conflicts when statically linked. Those functions
>> probably should be renamed completely to prevent this kind of problem.
> Are you saying that symbols with internal, static linkage inside bdw-gc
> conflict with static symbols inside Guile?  This sounds like a
> misconfiguration issue.
That problem I really have on Linux too. I build my own gc for static 
linking, and I pass the relevant environment variables to configure (I 
don't rely in pkg-config, because it is not easily available on windows) 
.You should be able to reproduce it, with my little test project. But 
when I don't pass those CPP guards to configure, I get compile errors.

>> Then there is also the old problem of the conflicting definitions of
>> struct timespec on MinGW in time.h and pthreads.h.
> FWIW I did not experience this in my cross-compile.
That's a very old and nasty problem with the pthread headers on windows. 
When I was searching I found people having problems with that for years 
and years.

>
>> The bug #13768 about scm_getpid being used in "--without-posix" builds I
>> have sent already.
> Fixed upstream; thanks.
>
>> Also, on mingw the guile-tools/guild copy script can't deal with the
>> .exe ending. I have to configure and make once with
>> --program-suffix=.exe to create the proper script names and files, and
>> then again without, so they can be copied. (or find and copy them by
>> hand between builds)
> Are you certain that the meta/guile and meta/guild scripts need the .exe
> extension?  They are not EXE files.  MinGW should add on .exe to
> programs like libguile/guile (NB: not meta/guile) as needed.
>
> Also note that I just fixed a bug in meta/guile in which it was
> referencing libguile/guile without the @EXEEXT@.
>
> Basically I think --program-suffix is not what you want.

I guess You can really only reproduce that on windows, since that really 
has to do with how windows treats paths and executable file names.
>> But then on install (processing .texi files) guile.exe fails with this
>> message:
>>
>> "Throw without catch before boot:
>> Throw to key system-error with args ("canonicalize-path" "~A" ("No such
>> file or directory") (2))Aborting.
> This is fixed in git, I believe.
>
> I think we're close.  Can you give it another try?  If needed I can
> handle the autogen side of things and give you a freshly prepared
> tarball.
I tried today with this tarball: 
http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz
Seems to have a gcc check error where a capital -V option is passed and 
it fails. Summary in previous email to this bug thread.

> Andy

I will keep trying of course. I can foresee a lot of problems with 
libreadline and similar loadable modules that use external dynamic 
libraries that don't come in a standard windows install on windows too. 
But I plan to make some changes/patches to the load paths anyway, so 
they work the same everywhere for my program, so I can address that there.

But until then I first need to get something that properly builds 
everywhere reliably.


Regards

Jan Schukat

[-- Attachment #2: guiletest.tgz --]
[-- Type: application/x-compressed-tar, Size: 2467 bytes --]