bug-texinfo
[Top][All Lists]
Advanced

[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: Mon, 19 Sep 2016 12:09:56 +0100

On 14 September 2016 at 19:55, Eli Zaretskii <address@hidden> wrote:
>> From: Gavin Smith <address@hidden>
>> Date: Wed, 14 Sep 2016 19:14:39 +0100
>> Cc: Texinfo <address@hidden>
>>
>> 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.
>
> Yes, but that is dangerous, since we should really heed to what Perl
> says.  It also requires to run Perl by hand, to get the compiler
> command, and then use it in PERL_EXT_CC.  OTOH, adding switches that
> don't contradict what Perl requires should be harmless.

It could be useful for someone to run Perl by hand to get the compiler
command, because then they would think about what switches were needed
for the compiler that Perl specified.

>> > 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.
>
> I think it isn't standard because libtool will ignore most switches.

I realised that it isn't standard because they can use CC then.

> If you are asking specifically in the context of Texinfo and Perl
> extensions, then it seems to me that LDFLAGS cannot be used here for
> the same reason CC cannot: Perl might require different switches than
> when linking, say, the stand-alone Info reader.

LDFLAGS should only be used for linking, not compiling, and appending
PERL_EXT_LDFLAGS to CC would use it for compiling as well. Now I admit
that I don't know if this matters in practice. But there's a risk that
there is some compiler that (a) someone wants to give extra flags to
for linking, and (b) those extra flags wouldn't work for compiling
object files. If someone had a Perl installation that specified such a
compiler, then if the build system appended PERL_EXT_LDFLAGS to CC,
then there would be no way for that person to do what they want. On
the other hand, having a separate PERL_EXT_CC would give more
flexibility in various circumstances.

(example:

$ cc -L/usr/local/lib -c foo.c
Error: Can't use -L flag to build foo.o

Some combination of compiler choice and LDFLAGS could give a result like this.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]