[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Perl compilation/link flags for building XSParagraph
From: |
Gavin Smith |
Subject: |
Re: Perl compilation/link flags for building XSParagraph |
Date: |
Wed, 14 Sep 2016 19:14:39 +0100 |
On 14 September 2016 at 19:01, Eli Zaretskii <address@hidden> wrote:
> The configure script's help says near its end:
>
> PERL_EXT_CFLAGS
> Compiler flags for a Perl extension
> PERL_EXT_CPPFLAGS
> C preprocessor flags for a Perl extension
> PERL_EXT_LDFLAGS
> Linker flags for a Perl extension
>
> The Makefile created in tp/Texinfo/Convert/XSParagraph leaves these
> variables undefined, so that they could be set by the user:
>
> # PERL_EXT_var are user variables, allowing configuring at the top-level
> # with e.g. "./configure CFLAGS='-g -O0' PERL_EXT_CFLAGS='-g'".
>
> The Makefile then inserts the values of these variables into the
> corresponding libtool commands, e.g.:
>
> LDFLAGS = $(PERL_EXT_LDFLAGS)
>
> I needed to use PERL_EXT_LDFLAGS today, in order to pass
> "-static-libgcc" to GCC (thus avoiding run-time dependency on the
> libgcc shared library, which gets in the way when building Texinfo on
> onesystem, then installing the binaries on another). I found that the
> switch is being ignored in the link command to build the XSParagraph
> shared library.
>
> After some digging, it turns out that libtool ignores any switches it
> doesn't understand when issuing the link command. The usual trick for
> this is to configure with CC='gcc -static-libgcc' (because the value
> of $CC does get used verbatim by libtool). However, in this
> particular case, this trick doesn't work, because the configure script
> in tp/Texinfo/Convert/XSParagraph forcefully ignores the top-level
> value of CC, since it needs to use the compiler requested by Perl.
>
> I found no way out of this conundrum, and ended up editing the libtool
> script by hand to inject -static-libgcc into the value of CC it
> records.
What comes to mind is to use another variable PERL_EXT_CC which would
be set in the same way as CC, assuming that is a valid trick to use
with libtool. configure.ac could check if PERL_EXT_CC is defined, and
if it is, use its value as the value of CC instead of using the
compiler that Perl says it needs.
>
> Bottom line, I think that the XSParagraph configure script should
> append the value of PERL_EXT_LDFLAGS to the value of CC it uses when
> it builds the libtool script, because otherwise most values of that
> variable will have no effect. Not sure if the same problem exists
> with PERL_EXT_CFLAGS and PERL_EXT_CPPFLAGS.
Wouldn't this reasoning also apply if LDFLAGS was being set directly
by the user, not via PERL_EXT_LDFLAGS? But it is not standard practice
AFAIK always to append LDFLAGS to CC when using libtool.