How can I link with libguile?
Here are the parameters:
1. I cannot rely on `guile-config'. It is often installed
without that script.
2. I tried a macro AG_WITHLIB_GUILE which does the following:
a) accepts --with-libguile, --with-libguile-incdir and
--with-libguile-libdir
b) If any of these are provided, LIBS and CPPFLAGS are
appropriately modified
c) presumably using those environment variables, (eval $ac_link) 2>&5
will try to link this program:
> #include
> int main () {
> SCM fumble, bumble, stumble;
> stumble = scm_cons( fumble, bumble );
> stumble = scm_display( fumble, bumble );
> stumble = scm_ilength( fumble );
> stumble = scm_makstr( 1, 2 );
> stumble = gh_eval_str( "stumble" );
> scm_misc_error( "oops", "bad", bumble );
> stumble = scm_num_eq_p( fumble, bumble );
> scm_wrong_type_arg( "oops", 1, bumble );
> return 0; }
d) if all that fails, then `guile-config' is consulted.
3. on the Source Forge Solaris build farm, this links:
> checking whether with-libguile was specified... no
> checking whether with-libguile-incdir was specified... no
> checking whether with-libguile-libdir was specified... no
> checking whether libguile can be linked with... yes
consequently, `guile-config' is not consulted. It is not
consulted because libguile.h was included successfully and
the link for the above works.
4. HOWEVER:
$ ../autogen-5.5.2pre3/configure \
--prefix=/home/users/b/bk/bkorb \
--bindir=/home/users/b/bk/bkorb/bin/sun4u-SunOS-5.8 \
--libdir=/home/users/b/bk/bkorb/lib/sun4u-SunOS-5.8
[[...]]
$ make
[[...]]
/bin/bash ../libtool --mode=link gcc -g -O2-o autogen \
-export-dynamic -lguile autogen-*.o ../autoopts/libopts.la \
-lm -ldl -lgen
mkdir .libs
gcc -g -O2 -o .libs/autogen autogen-*.o -lguile \
../autoopts/.libs/libopts.so -lm -lm -lm -lm -ldl -lgen \
-R/home/users/b/bk/bkorb/lib/sun4u-SunOS-5.8
creating autogen
[[...]]
top_builddir=.. \
../agen5/autogen -L ../../autogen-5.5.2pre3/autoopts \
-Taginfo -bcolumns -DLEVEL=section \
../../autogen-5.5.2pre3/columns/opts.def
ld.so.1: autogen: fatal: libguile.so.6: open failed: No such file or directory
*** Signal 9
make: Fatal error: Command failed for target `gen-stamp'
Current working directory /home/users/b/bk/bkorb/=sun4u-SunOS-5.8/columns
``libguile'' lives in a place where LD_LIBRARY_PATH must be set
(viz., /opt/sfw/lib). What is wrong? What should I be doing to
tell libtool that it has to add a ``-R/opt/sfw/lib'' or something?
If I use ``guile-config'' first, I'll override ``--with-libguile''.
So much pain. :-(
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: How can I link with libguile?
Bruce Korb wrote: Here are the parameters: 1. I cannot rely on `guile-config'. It is often installed without that script. Is guile-config reliably installed for versions of guile later than some number X? In that case, maybe you could simply require version X or later... I do sympathize. I cross-compile lots of stuff, and only recently have I learned how to deal with foo-config scripts in that context. (Only just recently got a grip on libtool, too.) - Dan ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How can I link with libguile?
On Sun, Jan 12, 2003 at 04:24:02PM -0800, Bruce Korb wrote: > ``libguile'' lives in a place where LD_LIBRARY_PATH must be set > (viz., /opt/sfw/lib). What is wrong? What should I be doing to > tell libtool that it has to add a ``-R/opt/sfw/lib'' or something? > If I use ``guile-config'' first, I'll override ``--with-libguile''. > So much pain. :-( We solve this by building like so: $ LDFLAGS="-R[path to guile library]" ./configure And, in the specific case of guile, we modify guile-config to output -L[path to guile libraries] *and* -R[path to guile libraries]. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How can I link with libguile?
Albert Chin wrote:
>
> On Sun, Jan 12, 2003 at 04:24:02PM -0800, Bruce Korb wrote
in http://mail.gnu.org/archive/html/libtool/2003-01/msg00035.html :
> > ``libguile'' lives in a place where LD_LIBRARY_PATH must be set
> > (viz., /opt/sfw/lib). What is wrong? What should I be doing to
> > tell libtool that it has to add a ``-R/opt/sfw/lib'' or something?
> > If I use ``guile-config'' first, I'll override ``--with-libguile''.
> > So much pain. :-(
>
> We solve this by building like so:
> $ LDFLAGS="-R[path to guile library]" ./configure
>
> And, in the specific case of guile, we modify guile-config to output
> -L[path to guile libraries] *and* -R[path to guile libraries].
:-(
Several problems:
1. There seems to be something funny about the way links work on
the Source Forge compile farm. The linker (invoked as "gcc")
knows where to find free software libraries ("/opt/fsw/lib"),
but it doesn't pass this knowledge along to the run time loader.
Is this expected behavior, or a Source Forge issue? Should my
link test be changed to a run test? Doing that would trigger
the invocation of "guile-config". In any event, on the compile
farm, my test believes that it can compile and link without
anything more special than ``-lguile'' on the link line (no "-I"
either).
2. On Solaris, libtool ought to take "-L" args and duplicate them
as "-R" args, yes? Or, is that too simple?
3. As the author of a *-config script, how would I know when to
add the "-R" thingey? Would libtool strip it if it weren't
needed on a particular platform? Do you (Albert) add the
-R/path/to/libopts on my script, too? Is there a configure
test to check for the need of adding "-R"?
4. Your solutions work well for your environment: you are in control
of the production of your binaries. My problem is that I am trying
(with amazing amounts of frustration ;) to produce scripts that
allow my clients to build and install products with:
( gunzip -c product*.tar.gz | tar -xvf - ) && \
cd product* && \
./configure && \
make && \
make install
without having to know or understand the configury of Guile and
the magical linker options for any particular platform. In theory,
that is what autoconf/automake/libtool are all about. :(
P.S.: Dan Kegel asked:
> Is guile-config reliably installed for versions of guile
> later than some number X?
Answer: No. It is a special issue with Red Hat. They set the
prefix to "/usr" so that no special configury is required, so
nobody needs to consult "guile-config". That means that just
because you cannot find "guile-config" it doesn't mean that
Guile has not been installed. SO: step 1, let someone tell you
where to find it. Failing that, step 2, try to use it anyway.
If *that* fails, then, finally, go find "guile-config". Maybe
I should switch steps 2 and 3, but it led to such a complicated
shell script/autoconf macroRed Hat should distribute the script.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: How can I link with libguile?
On Mon, Jan 13, 2003 at 10:16:04AM -0800, Bruce Korb wrote:
> Albert Chin wrote:
> >
> > On Sun, Jan 12, 2003 at 04:24:02PM -0800, Bruce Korb wrote
> in http://mail.gnu.org/archive/html/libtool/2003-01/msg00035.html :
> > > ``libguile'' lives in a place where LD_LIBRARY_PATH must be set
> > > (viz., /opt/sfw/lib). What is wrong? What should I be doing to
> > > tell libtool that it has to add a ``-R/opt/sfw/lib'' or something?
> > > If I use ``guile-config'' first, I'll override ``--with-libguile''.
> > > So much pain. :-(
> >
> > We solve this by building like so:
> > $ LDFLAGS="-R[path to guile library]" ./configure
> >
> > And, in the specific case of guile, we modify guile-config to output
> > -L[path to guile libraries] *and* -R[path to guile libraries].
>
> :-(
>
> Several problems:
>
> 1. There seems to be something funny about the way links work on
> the Source Forge compile farm. The linker (invoked as "gcc")
> knows where to find free software libraries ("/opt/fsw/lib"),
> but it doesn't pass this knowledge along to the run time loader.
> Is this expected behavior, or a Source Forge issue? Should my
> link test be changed to a run test? Doing that would trigger
> the invocation of "guile-config". In any event, on the compile
> farm, my test believes that it can compile and link without
> anything more special than ``-lguile'' on the link line (no "-I"
> either).
Run with gcc -v and see what's happening. If during the build of
autogen you must run a program which depends on libguile, change your
link to a test.
> 2. On Solaris, libtool ought to take "-L" args and duplicate them
> as "-R" args, yes? Or, is that too simple?
*ICK* *ICK* *ICK*!
> 3. As the author of a *-config script, how would I know when to
> add the "-R" thingey? Would libtool strip it if it weren't
> needed on a particular platform? Do you (Albert) add the
> -R/path/to/libopts on my script, too? Is there a configure
> test to check for the need of adding "-R"?
I add -R/path/to/libopts for *every* *-config script (ditto for
pkgconfig scripts). Testing for -R won't help you on Tru64 UNIX, IRIX,
Redhat Linux, AIX, etc. Libtool does accept -R/path/to/lib and will
convert -R to the proper switch for the platform in question. However,
this doesn't help during ./configure.
> P.S.: Dan Kegel asked:
> > Is guile-config reliably installed for versions of guile
> > later than some number X?
>
> Answer: No. It is a special issue with Red Hat. They set the
> prefix to "/usr" so that no special configury is required, so
> nobody needs to consult "guile-config". That means that just
> because you cannot find "guile-config" it doesn't mean that
> Guile has not been installed. SO: step 1, let someone tell you
> where to find it. Failing that, step 2, try to use it anyway.
> If *that* fails, then, finally, go find "guile-config". Maybe
> I should switch steps 2 and 3, but it led to such a complicated
> shell script/autoconf macroRed Hat should distribute the script.
I think you should do the following:
1. Try to link and run against -lguile.
2. Look for guile-config and repeat #1.
3. Fail with a decent AC_ERROR.
At the same time, I'd add the following autoconf options:
--with-guile-config=[path to guile-config]
--with-guile=[base path of guile installation]
--with-guile-includes=[path to guile includes]
--with-guile-libraries=[path to guile libraries]
--with-guile would:
CPPFLAGS="$CPPFLAGS -I$withval/include"
LDFLAGS="$LDFLAGS -L$withval/lib"
--with-guile-includes would:
CPPFLAGS="$CPPFLAGS -I$withval/include"
--with-guile-libraries would:
LDFLAGS="$LDFLAGS -L$withval/lib"
--with-guile is of course optional if you choose --with-guile-includes
and --with-guile-libraries.
BTW, this is OT for libtool.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
