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