GNU bug report logs - #11089
LINK determination

Previous Next

To reply to this bug, email your comments to 11089 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jason DeVinney <jasondevinney <at> gmail.com>
Cc: bug-automake <at> gnu.org, automake <at> gnu.org
Subject: Re: LINK determination
Date: Sun, 25 Mar 2012 17:20:16 +0200

Severity: minor

[CC:ing bug-automake, so that we won't forget about the issue]

On 03/23/2012 03:32 AM, Jason DeVinney wrote:
> Hi all,
>
Hi Jason, sorry for the delay.

> I have a upc program with *.upc source files. I have some macros that
> make UPC code look effectively like C code and so it is easy to
> compile this program as a C program as well. My Makefile.am has the
> following lines
> 
> bin_PROGRAMS = foo
> common_sources = file1.upc file2.upc
> 
> if BUILD_UPC
>  foo_LINK = $(UPCLINK)
>  foo_SOURCES = $(common_sources)
> else
>  foo_LINK = $(LINK)
>  foo_SOURCES = $(common_sources:.upc=_c.c)
> fi
> 
> I also have some code in my Makefile.am to tell make how to create
> (with links) the file1_c.c and file2_c.c files. The BUILD_UPC variable
> is set with AC_SUBST in my configure.ac based on a configure option
> (--disable-upc). If no option is given then BUILD_UPC is set to 1, but
> if --disable-upc is given BUILD_UPC is zero. automake is correctly
> automatically determining which compiler to use in both cases, but for
> some reason it wants to use the UPCLINK linker in both cases. I read
> section 8.13.3.1 How the Linker is Chosen, in the automake
> documentation and it says that automake determines which linker to use
> based on the foo_SOURCES variable, so I can't see why I need to
> include the two foo_LINK lines in my Makefile.am (I would like to
> avoid this). Does anyone know why this is happening? Am I forgetting
> something?
>
I'd describe this as an automake limitation; not sure if it's worth
fixing (since yours is not a common use case, and the issue you're
facing has a simple-enough workaround, as you've already found out);
but it would be worth documenting IMHO.  Care to write a patch?
Otherwise, I'll try to cook one up myself before the 1.11.4 release
(but I'm short of time these days, so no promise).

Thanks,
  Stefano

Message #10 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jason DeVinney <jasondevinney <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, automake <at> gnu.org
Subject: Re: LINK determination
Date: Mon, 26 Mar 2012 12:44:15 -0400

Stefano,

Thanks for the reply. I am satisfied with this. I just wanted to make
sure I wasn't missing something.

Cheers,
Jason

On Sun, Mar 25, 2012 at 11:20 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> Severity: minor
>
> [CC:ing bug-automake, so that we won't forget about the issue]
>
> On 03/23/2012 03:32 AM, Jason DeVinney wrote:
>> Hi all,
>>
> Hi Jason, sorry for the delay.
>
>> I have a upc program with *.upc source files. I have some macros that
>> make UPC code look effectively like C code and so it is easy to
>> compile this program as a C program as well. My Makefile.am has the
>> following lines
>>
>> bin_PROGRAMS = foo
>> common_sources = file1.upc file2.upc
>>
>> if BUILD_UPC
>>  foo_LINK = $(UPCLINK)
>>  foo_SOURCES = $(common_sources)
>> else
>>  foo_LINK = $(LINK)
>>  foo_SOURCES = $(common_sources:.upc=_c.c)
>> fi
>>
>> I also have some code in my Makefile.am to tell make how to create
>> (with links) the file1_c.c and file2_c.c files. The BUILD_UPC variable
>> is set with AC_SUBST in my configure.ac based on a configure option
>> (--disable-upc). If no option is given then BUILD_UPC is set to 1, but
>> if --disable-upc is given BUILD_UPC is zero. automake is correctly
>> automatically determining which compiler to use in both cases, but for
>> some reason it wants to use the UPCLINK linker in both cases. I read
>> section 8.13.3.1 How the Linker is Chosen, in the automake
>> documentation and it says that automake determines which linker to use
>> based on the foo_SOURCES variable, so I can't see why I need to
>> include the two foo_LINK lines in my Makefile.am (I would like to
>> avoid this). Does anyone know why this is happening? Am I forgetting
>> something?
>>
> I'd describe this as an automake limitation; not sure if it's worth
> fixing (since yours is not a common use case, and the issue you're
> facing has a simple-enough workaround, as you've already found out);
> but it would be worth documenting IMHO.  Care to write a patch?
> Otherwise, I'll try to cook one up myself before the 1.11.4 release
> (but I'm short of time these days, so no promise).
>
> Thanks,
>  Stefano

Message #13 received at 11089 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jason DeVinney <jasondevinney <at> gmail.com>
Cc: 11089 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
	Automake List <automake <at> gnu.org>
Subject: Re: bug#11089: LINK determination
Date: Tue, 27 Mar 2012 15:27:31 +0200

[Message part 1 (text/plain, inline)]

[Adding automake-patches]

Reference: <http://debbugs.gnu.org/11089>

> On Sun, Mar 25, 2012 at 11:20 AM, Stefano Lattarini wrote:
>
> I'd describe this as an automake limitation; not sure if it's worth
> fixing (since yours is not a common use case, and the issue you're
> facing has a simple-enough workaround, as you've already found out);
> but it would be worth documenting IMHO.
>
On a second thought, I've been unable to find a way to document Jason's
workaround that doesn't sound cumbersome and clumsy; so maybe it's better
to just drop this documentation change.

Still, having a test case verifying that such a workaround actually works
is still worthwhile and easy to do.  This is what the attached patch does.
I will push it this evening or tomorrow if there is no objection.

Regards,
  Stefano

[0001-tests-workaround-for-automatic-linker-determination-.patch (text/x-diff, attachment)]

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Breitenlohner <peb <at> mppmu.mpg.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11089 <at> debbugs.gnu.org, bug-automake <at> gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
	Automake List <automake <at> gnu.org>
Subject: Re: bug#11089: LINK determination
Date: Wed, 28 Mar 2012 13:30:52 +0200 (CEST)

On Tue, 27 Mar 2012, Stefano Lattarini wrote:

> [Adding automake-patches]
>
> Reference: <http://debbugs.gnu.org/11089>
>
>> On Sun, Mar 25, 2012 at 11:20 AM, Stefano Lattarini wrote:
>>
>> I'd describe this as an automake limitation; not sure if it's worth
>> fixing (since yours is not a common use case, and the issue you're
>> facing has a simple-enough workaround, as you've already found out);
>> but it would be worth documenting IMHO.

this situation is actually more common than one might think.  E.g., the
Makefile.am for gnuplot-4.6.0/src/ contains
	gnuplot_SOURCES = alloc.c ETC.
	if BUILD_WXWIDGETS
	gnuplot_SOURCES += wxterminal/wxt_gui.cpp
	endif
but that actually ought to be
	gnuplot_SOURCES = alloc.c ETC.
	if BUILD_WXWIDGETS
	gnuplot_SOURCES += wxterminal/wxt_gui.cpp
	gnuplot_LINK = $(CXXLINK)
	else
        gnuplot_LINK = $(LINK)
	endif

> On a second thought, I've been unable to find a way to document Jason's
> workaround that doesn't sound cumbersome and clumsy; so maybe it's better
> to just drop this documentation change.
>
> Still, having a test case verifying that such a workaround actually works
> is still worthwhile and easy to do.  This is what the attached patch does.
> I will push it this evening or tomorrow if there is no objection.

the workaround described earlier in this thread and used in the test case:
	if HAVE_CXX
	foo_LINK = $(CXXLINK)
	else
	foo_LINK = $(LINK)
	endif
works nicely and is simple enough when not using libtool libraries.  When
linking foo with (installed or uninstalled) libtool libraries, the default
definition of foo_LINK generated by Automake would be something like
	foo_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
	        --mode=link $(CXXLD) $(foo_CXXFLAGS) $(CXXFLAGS) \
	        $(foo_LDFLAGS) $(LDFLAGS) -o $@
and a more elaborate workaround is needed.

What is the best way to handle this situation?  An additional test case?

Regards
Peter Breitenlohner <peb <at> mppmu.mpg.de>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.