Patchwork [2/2] libcacard: add libcacard.la target

login
register
mail settings
Submitter Alon Levy
Date May 15, 2011, 3:40 p.m.
Message ID <1305474018-23235-3-git-send-email-alevy@redhat.com>
Download mbox | patch
Permalink /patch/95652/
State New
Headers show

Comments

Alon Levy - May 15, 2011, 3:40 p.m.
No flag to configure is required. Instead, added a libcacard.la target that
is not built by default, only when requested explicitly via:

mkdir build
cd build
../configure
make libcacard.la
make install-libcacard

Uses libtool to do actual linking of object files and shared library, and
installing. Tested only under linux, but supposed to work on other systems as
well.

Signed-off-by: Alon Levy <alevy@redhat.com>
---
 Makefile           |    9 +++++++++
 configure          |    2 +-
 libcacard/Makefile |   30 ++++++++++++++++++++++++++----
 3 files changed, 36 insertions(+), 5 deletions(-)
Paolo Bonzini - May 16, 2011, 7 a.m.
On 05/15/2011 05:40 PM, Alon Levy wrote:
> -    ln -s "$source_path/libcacard/Makefile" libcacard/Makefile
> +    ln -s -f "$source_path/libcacard/Makefile" libcacard/Makefile

Use the "symlink" function rather than ln -s -f for portability to 
broken platforms, please.

Note that this requires libtool at build time rather than only for 
maintainers.  This is unlike all other software using it.  However, I 
believe this is not too bad given that a special make invocation is 
required.

Paolo
Alon Levy - May 16, 2011, 10:25 a.m.
On Mon, May 16, 2011 at 09:00:10AM +0200, Paolo Bonzini wrote:
> On 05/15/2011 05:40 PM, Alon Levy wrote:
> >-    ln -s "$source_path/libcacard/Makefile" libcacard/Makefile
> >+    ln -s -f "$source_path/libcacard/Makefile" libcacard/Makefile
> 
> Use the "symlink" function rather than ln -s -f for portability to
> broken platforms, please.
ok.

> 
> Note that this requires libtool at build time rather than only for
> maintainers.  This is unlike all other software using it.  However,
> I believe this is not too bad given that a special make invocation
> is required.

I was under the impression this was the way to use libtool (I've basically
followed the manual). Is there another way that is better?

> 
> Paolo
Paolo Bonzini - May 16, 2011, 10:32 a.m.
On 05/16/2011 12:25 PM, Alon Levy wrote:
> >  Note that this requires libtool at build time rather than only for
> >  maintainers.  This is unlike all other software using it.  However,
> >  I believe this is not too bad given that a special make invocation
> >  is required.
>
> I was under the impression this was the way to use libtool (I've basically
> followed the manual). Is there another way that is better?

Without using Autoconf, this is the way.

Usually programs that are fully autoconf-iscated will ship a subset of 
libtool sources in the tarball, build a custom version at configure 
time, and invoke it from the Makefile via ./libtool.  This has the 
advantage that only the maintainer needs to have libtool installed. 
OTOH we do not use Autoconf and I think this contributes to 99% of the 
bad name for Autoconf, so it's not something we want.

Paolo
Gerd Hoffmann - May 16, 2011, 12:06 p.m.
Hi,

> Usually programs that are fully autoconf-iscated will ship a subset of
> libtool sources in the tarball, build a custom version at configure
> time, and invoke it from the Makefile via ./libtool. This has the
> advantage that only the maintainer needs to have libtool installed. OTOH
> we do not use Autoconf and I think this contributes to 99% of the bad
> name for Autoconf, so it's not something we want.

Another option would be to not use autoconf at all.  Building ELF shared 
libs isn't that difficuilt these days.  Question is whenever there is 
any non-ELF platform we care about (Windows maybe?).

cheers,
   Gerd
Paolo Bonzini - May 16, 2011, 12:07 p.m.
On 05/16/2011 02:06 PM, Gerd Hoffmann wrote:
>> Usually programs that are fully autoconf-iscated will ship a subset of
>> libtool sources in the tarball, build a custom version at configure
>> time, and invoke it from the Makefile via ./libtool. This has the
>> advantage that only the maintainer needs to have libtool installed. OTOH
>> we do not use Autoconf and I think this contributes to 99% of the bad
>> name for Autoconf, so it's not something we want.
>
> Another option would be to not use autoconf at all.
                                      ^^^^^^^^

You probably mean libtool?

> Building ELF shared
> libs isn't that difficuilt these days. Question is whenever there is any
> non-ELF platform we care about (Windows maybe?).

... and Darwin?

Paolo
Alon Levy - May 16, 2011, 12:14 p.m.
On Mon, May 16, 2011 at 02:07:55PM +0200, Paolo Bonzini wrote:
> On 05/16/2011 02:06 PM, Gerd Hoffmann wrote:
> >>Usually programs that are fully autoconf-iscated will ship a subset of
> >>libtool sources in the tarball, build a custom version at configure
> >>time, and invoke it from the Makefile via ./libtool. This has the
> >>advantage that only the maintainer needs to have libtool installed. OTOH
> >>we do not use Autoconf and I think this contributes to 99% of the bad
> >>name for Autoconf, so it's not something we want.
> >
> >Another option would be to not use autoconf at all.
>                                      ^^^^^^^^
> 
> You probably mean libtool?
> 
> >Building ELF shared
> >libs isn't that difficuilt these days. Question is whenever there is any
> >non-ELF platform we care about (Windows maybe?).
> 
> ... and Darwin?
> 

For linux all that is needed is to recompile all required sources with -fPIC (doesn't
make sense to force that on the objects linked to the rest of qemu), and link them with
gcc -shared. Does that work on Darwin? on Windows (mingw / cygwin)?

> Paolo
>
Paolo Bonzini - May 16, 2011, 12:18 p.m.
On 05/16/2011 02:14 PM, Alon Levy wrote:
> On Mon, May 16, 2011 at 02:07:55PM +0200, Paolo Bonzini wrote:
>> On 05/16/2011 02:06 PM, Gerd Hoffmann wrote:
>>>> Usually programs that are fully autoconf-iscated will ship a subset of
>>>> libtool sources in the tarball, build a custom version at configure
>>>> time, and invoke it from the Makefile via ./libtool. This has the
>>>> advantage that only the maintainer needs to have libtool installed. OTOH
>>>> we do not use Autoconf and I think this contributes to 99% of the bad
>>>> name for Autoconf, so it's not something we want.
>>>
>>> Another option would be to not use autoconf at all.
>>                                       ^^^^^^^^
>>
>> You probably mean libtool?
>>
>>> Building ELF shared
>>> libs isn't that difficuilt these days. Question is whenever there is any
>>> non-ELF platform we care about (Windows maybe?).
>>
>> ... and Darwin?
>>
>
> For linux all that is needed is to recompile all required sources with -fPIC (doesn't
> make sense to force that on the objects linked to the rest of qemu), and link them with
> gcc -shared. Does that work on Darwin? on Windows (mingw / cygwin)?

No :(

Windows is a total mess, but Darwin is only slightly better and the 
naming conventions differ too (.dylib instead of .so for example).

Paolo

Patch

diff --git a/Makefile b/Makefile
index 2b0438c..4bb6ca6 100644
--- a/Makefile
+++ b/Makefile
@@ -120,6 +120,15 @@  version.o: $(SRC_PATH)/version.rc config-host.mak
 version-obj-$(CONFIG_WIN32) += version.o
 ######################################################################
 
+.PHONY: libcacard.la install-libcacard
+libcacard.la: $(GENERATED_HEADERS) $(oslib-obj-y) qemu-malloc.o qemu-timer-common.o $(trace-obj-y)
+	$(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C libcacard V="$(V)" TARGET_DIR="$*/" libcacard.la,)
+
+install-libcacard: libcacard.la
+	$(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C libcacard V="$(V)" TARGET_DIR="$*/" install-libcacard,)
+
+######################################################################
+
 qemu-img.o: qemu-img-cmds.h
 qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o: $(GENERATED_HEADERS)
 
diff --git a/configure b/configure
index 0627f1d..26e32f3 100755
--- a/configure
+++ b/configure
@@ -3595,7 +3595,7 @@  if [ "$source_path" != `pwd` ]; then
     # out of tree build
     mkdir -p libcacard
     rm -f libcacard/Makefile
-    ln -s "$source_path/libcacard/Makefile" libcacard/Makefile
+    ln -s -f "$source_path/libcacard/Makefile" libcacard/Makefile
 fi
 
 d=libuser
diff --git a/libcacard/Makefile b/libcacard/Makefile
index 1d34df0..8abad26 100644
--- a/libcacard/Makefile
+++ b/libcacard/Makefile
@@ -4,15 +4,37 @@ 
 
 $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/libcacard)
 
-QEMU_OBJS=$(addprefix ../, $(oslib-obj-y) $(trace-obj-y) qemu-malloc.o qemu-timer-common.o)
+QEMU_TRACE_OBJS=$(addprefix ../,$(trace-obj-y))
+
+QEMU_BASE_OBJS=$(addprefix ../,$(oslib-obj-y) qemu-malloc.o qemu-timer-common.o)
+
+# objects linked against normal qemu binaries, not compiled with libtool
+QEMU_OBJS = $(QEMU_BASE_OBJS) $(QEMU_TRACE_OBJS)
+
+# objects linked into a shared library, built with libtool with -fPIC if required
+QEMU_BASE_OBJS_LIB=$(addsuffix .lo,$(basename $(QEMU_BASE_OBJS)))
+
+QEMU_OBJS_LIB = $(QEMU_BASE_OBJS_LIB) $(QEMU_TRACE_OBJS)
 
 QEMU_CFLAGS+=-I../
 
+libcacard.lib-y=$(addsuffix .lo,$(basename $(libcacard-y)))
+
 vscclient: $(libcacard-y) $(QEMU_OBJS) vscclient.o
-	$(call quiet-command,$(CC) $(libcacard_libs) -lrt -o $@ $^,"  LINK  $(TARGET_DIR)$@")
+	$(call quiet-command,$(CC) $(libcacard_libs) -lrt -o $@ $^,"  LINK  $@")
 
-all: vscclient
+$(libcacard.lib-y) $(QEMU_BASE_OBJS_LIB) : %.lo: %.c
+	$(call quiet-command,libtool --mode=compile --quiet --tag=CC $(CC) $(QEMU_CFLAGS) $(QEMU_INCLUDES) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  lt CC $@")
+
+libcacard.la: $(libcacard.lib-y) $(QEMU_OBJS_LIB)
+	$(call quiet-command,libtool --mode=link --quiet --tag=CC $(CC) $(libcacard_libs) -lrt -rpath $(libdir) -o $@ $^,"  lt LINK $@")
 
 clean:
-	rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ vscclient
+	rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ vscclient libcacard.so *.lo .libs/* *.la
+	rm -Rf .libs
 
+install-libcacard: libcacard.la
+	$(INSTALL_DIR) "$(DESTDIR)$(libdir)"
+	libtool --mode=install $(INSTALL_PROG) libcacard.la "$(DESTDIR)$(libdir)"
+
+all: vscclient