[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How can I link with libguile?
From: |
Bruce Korb |
Subject: |
Re: How can I link with libguile? |
Date: |
Mon, 13 Jan 2003 10:16:04 -0800 |
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 macro....Red Hat should distribute the script.