[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Again on Windows support (2)
From: |
carlo\.bramix |
Subject: |
Re: Again on Windows support (2) |
Date: |
Fri, 26 Jun 2009 20:45:25 +0200 |
Hello,
the problem with the library installed into /lib directory instead of /bin is
caused by "-module" parameter into LDFLAGS.
This parameter should be moved into configure script and it must be used for
platforms that really need it (at least, not for mingw and cygwin).
I also removed the "-lguile" parameter from LDFLAGS because it must use what it
has been written into LIBADD.
I did this change and it worked fine on cygwin and linux Debian 5.0
Sincerely,
Carlo Bramini.
---------- Initial Header -----------
>From : address@hidden
To : "guile-devel" address@hidden
Cc :
Date : Mon, 22 Jun 2009 12:22:33 +0200
Subject : Re: Again on Windows support (2)
> Hello,
> adding "-export-dynamic -no-undefined" fixed guile under cygwin.
> Both "make" and "make install" are now executed without troubles. Success!
> But unfortunately there is still one bit left: when doing "make install" the
> file cygguile-i18n-v-0-0.dll is installed into /lib directory instead of /bin.
> All other DLL are correctly installed into /bin directory, just this one is
> an exception.
> I have not idea why it happens... I hope someone has an explanation...
> BTW, I have also a doubt: I changed that stuff in libguile/Makefile.am in
> this manner:
>
> address@hidden@_la_LIBADD = \
> libguile.la $(gnulib_library)
>
> address@hidden@_la_LDFLAGS = \
> -module -L$(builddir) -lguile \
> -export-dynamic -no-undefined \
> -version-info @LIBGUILE_I18N_INTERFACE@
>
> but isn't the "-lguile" wrong into LDFLAGS? It should stay into LIBADD and
> hopefully we have already it with libguile.la
>
> Sincerely,
>
> Carlo Bramini.
>
> ---------- Initial Header -----------
>
> From : address@hidden
> To : "guile-devel" address@hidden
> Cc :
> Date : Mon, 22 Jun 2009 11:18:05 +0200
> Subject : Re: Again on Windows support (2)
>
> > Hello,
> > Bug found.
> > The problem seems to happen because the libguile-i18n-v-0 is missing these
> > flags: -export-dynamic -no-undefined
> > Infact it created a static library and not a DLL, I believe it failed for
> > this reason.
> > Now I try to quickly fix it, I will retest and I will report the result.
> >
> > Sincerely,
> >
> > Carlo Bramini.
> >
> >
> > ---------- Initial Header -----------
> >
> > From : "Andy Wingo" address@hidden
> > To : "carlo.bramix" address@hidden
> > Cc : "guile-devel" address@hidden
> > Date : Sat, 20 Jun 2009 12:53:48 +0200
> > Subject : Re: Again on Windows support (2)
> >
> > > On Fri 19 Jun 2009 21:11, "carlo.bramix" <address@hidden> writes:
> > >
> > > > Under Cygwin, compilation advanced much more with newer sources
> > > > (yeah!)
> > >
> > > Cool :)
> > >
> > > > but it gave another error:
> > > >
> > > > GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
> > > > "ice-9/i18n.
> > > > go" "ice-9/i18n.scm"
> > > > Backtrace:
> > > [...]
> > > > ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]
> > > >
> > > > <unnamed port>: In procedure dynamic-link in expression (load-extension
> > > > "libguile-i18n-v-0" "scm_init_i18n"):
> > > > <unnamed port>: file: "libguile-i18n-v-0", message: "can't open the
> > > > module"
> > >
> > > Perhaps something is wrong when linking this module. "Can't open the
> > > module" is not a very good warning :)
> > >
> > > If you've gotten to here, you might be able to run Guile:
> > >
> > > $ meta/guile
> > >
> > > If it doesn't error about srfi-1 lib loading, that means you do have
> > > dynamic library loading working, that it's just a problem with the i18n
> > > lib.
> > >
> > > Good luck,
> > >
> > > Andy
> > > --
> > > http://wingolog.org/
> > >
> >
> >
> >
> >
>
>
>
>
- Re: Again on Windows support (2), (continued)
- Re: Again on Windows support (2), carlo\.bramix, 2009/06/19
- Re: Again on Windows support (2), carlo\.bramix, 2009/06/19
- Re: Again on Windows support (2), carlo\.bramix, 2009/06/22
- Re: Again on Windows support (2), carlo\.bramix, 2009/06/22
- Re: Again on Windows support (2), carlo\.bramix, 2009/06/23
- Re: Again on Windows support (2),
carlo\.bramix <=