| Message ID | 1305474018-23235-3-git-send-email-alevy@redhat.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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 >
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
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
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(-)