GNU bug report logs - #25914
Please document compilation of Windows Resource files

Previous Next

Full log

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

From: Simon McVittie <smcv <at> collabora.com>
To: 25914 <at> debbugs.gnu.org
Cc: Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: Bug #25914: Please document compilation of Windows Resource files
Date: Mon, 9 Oct 2017 13:30:35 +0100

Reuben Thomas wrote:
> As suggested by the last message in that thread, the following seems to
> work:
>
> .rc.lo:
> $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=RC --mode=compile $(RC)
> $(RCFLAGS) $< -o $@

This came up during maintenance of dbus,
<https://bugs.freedesktop.org/show_bug.cgi?id=103015>. We have a resource
(versioninfo.rc) that we want to link into a libtool library, and also a
resource (disable-uac.rc) that we want to link into an executable.

For the libtool library, what Reuben said works: libtool knows how to
"compile" resource files into Libtool objects, but Automake does not
provide a .rc.lo implicit rule automatically, so we have to provide
our own. It wasn't clear to me whether this should result in an Automake
feature request (to provide such a rule automatically), or whether that
should be a Libtool feature request, or whether this is all working as
intended and users of this facility are expected to provide their own
implicit rule as Reuben did. For the moment we've done the same thing
Reuben suggested:

--------
SUFFIXES = .rc

.rc.lo:
	$(LIBTOOL) $(AM_V_lt) --tag=RC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(RC) $< -o $@

libdbus_1_la_SOURCES += versioninfo.rc
--------

For the executable, I found that I had to request compilation of a plain
object (.o) not a Libtool object (.lo), otherwise Automake 1.15.1
wouldn't realise that having $basename.rc in executable_SOURCES meant it
should include the corresponding $basename.o in executable_OBJECTS. This
worked with Debian's libtool 2.4.6-2 and Automake 1:1.15.1-3:

--------
SUFFIXES = .rc

.rc.o:
	$(LIBTOOL) $(AM_V_lt) --tag=RC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(RC) $< -o $@

nodist_dbus_update_activation_environment_SOURCES += disable-uac.rc
--------

However, another developer found that with an older libtool (openSUSE's
libtool 2.4.2-18.3.1 and automake 1.13.4-8.9), and that same make rule,
libtool/Automake would output the .o file in .libs/$basename.o but then
try to link $basename.o (without .libs) into the executable, causing a
build failure. Unfortunately, I wasn't able to find a git commit between
2.4.2 and 2.4.6 that looked like it fixed this. So we ended up with this
rule instead, using plain windres instead of libtool when linking the
resulting object into an executable:

--------
SUFFIXES = .rc

.rc.o:
	$(RC) $< -o $@

nodist_dbus_update_activation_environment_SOURCES += disable-uac.rc
--------

I would appreciate feedback from libtool developers on how much of this is
working as intended, and how much of it is a bug in either Automake or
libtool.

Thanks,
    smcv

Previous Next

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