[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problem with hardcode_libdir_flag_spec
From: |
Werner LEMBERG |
Subject: |
Re: problem with hardcode_libdir_flag_spec |
Date: |
Thu, 07 Feb 2013 13:02:59 +0100 (CET) |
This is a shy `ping' :-)
Werner
----------------------------------------------------------------------
> [libtool 2.4.2]
>
> Folks,
>
>
> let's assume that someone is doing
>
> AC_SUBST([libdir])
> AC_SUBST([wl])
> AC_SUBST([hardcode_libdir_flag_spec])
>
> and later tries to say
>
> libdir = @libdir@
> wl = @wl@
> hardcode_libdir_flag_spec = @hardcode_libdir_flag_spec@
>
> within a Makefile, as can be done with other such variables. [The
> idea is to construct a proper `-R' linker argument for a `--libs'
> option of a `foo-config' file generated at compile time, but this is a
> different issue.]
>
> However, this causes a very unpleasant surprise since the above
> snippet gets converted to
>
> libdir = /foo/bar
> wl = -Wl,
> hardcode_libdir_flag_spec = '${wl}-rpath ${wl}$libdir'
>
> Note the `$libdir' string which gets interpreted as variable `$l'
> followed by `ibdir' within a Makefile...
>
> Now my questions.
>
> . Is it a bug? It should be trivial IMHO to use ${libdir} instead
> to avoid incorrect Makefile variable expansion. I can imagine
> that other variables (even in autoconf or automake) are similarly
> affected.
>
> . Is it correct usage? I mean, is there a list of autotools
> variables which must not be used within a Makefile (after
> AC_SUBST)?
>
> . How can I circumvent the problem with the current libtool version?
>
>
> Werner