Roger Pau Monne
2011-Dec-18 12:48 UTC
[PATCH 0 of 5] build: various fixes for building with uclibc
This patch contains various fixes to the build system to allow building xen under uclibc. Has been tested with uclibc 0.9.32 and gcc 4.6.2, from Alpine Linux 2.3.2. Please review, Roger.
Roger Pau Monne
2011-Dec-18 12:48 UTC
[PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b
# Parent b783e76e63a99c9d87fca4974492f60af99a2e7a
blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
blktap was using defines set by qemu, even when the qemu config file
is not included. Remove this checkings, and instead check if the file
has been included before defining the necessary macros.
The output error is:
In file included from block-qcow.c:37:0:
bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h
--- a/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100
@@ -15,9 +15,7 @@
#define bswap_64(x) swap64(x)
#else
-#ifdef HAVE_BYTESWAP_H
-#include <byteswap.h>
-#else
+#ifndef _BYTESWAP_H
#define bswap_16(x) \
({ \
@@ -51,7 +49,7 @@
(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >>
56) )); \
})
-#endif /* !HAVE_BYTESWAP_H */
+#endif /* !_BYTESWAP_H */
static inline uint16_t bswap16(uint16_t x)
{
# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1324171782 -3600 # Node ID c54c326d6fdf26d311c872479b769b3a8cd560cf # Parent eed78eb655c40b0ac9af1b14c1cc03204f696b0b build: detect uclibc Detect uclibc build environment and define CONFIG_UCLIBC accordingly. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r eed78eb655c4 -r c54c326d6fdf Config.mk --- a/Config.mk Sun Dec 18 02:29:42 2011 +0100 +++ b/Config.mk Sun Dec 18 02:29:42 2011 +0100 @@ -18,6 +18,8 @@ XEN_TARGET_ARCH ?= $(XEN_COMPILE_ARC XEN_OS ?= $(shell uname -s) CONFIG_$(XEN_OS) := y +CONFIG_UCLIBC := $(shell gcc -dumpmachine | grep -c uclibc \ + | sed -e s/[^0]/y/ -e s/0/n/) SHELL ?= /bin/sh
Roger Pau Monne
2011-Dec-18 12:48 UTC
[PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1324171782 -3600 # Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb # Parent c54c326d6fdf26d311c872479b769b3a8cd560cf blktap2: fix vhd compilation under uclibc blktap2 was not compiled succesfully under uclibc, with the following error: gcc -o vhd-util vhd-util.o -Llib -lvhd lib/libvhd.so: undefined reference to `libiconv_open'' lib/libvhd.so: undefined reference to `libiconv_close'' lib/libvhd.so: undefined reference to `libiconv'' This patchs add the flag -liconv when blktap2/vhd is compiled on uclibc. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile --- a/tools/blktap2/drivers/Makefile Sun Dec 18 02:29:42 2011 +0100 +++ b/tools/blktap2/drivers/Makefile Sun Dec 18 02:29:42 2011 +0100 @@ -24,6 +24,10 @@ endif VHDLIBS := -L$(LIBVHDDIR) -lvhd +ifeq ($(CONFIG_UCLIBC),y) +VHDLIBS += -liconv +endif + REMUS-OBJS := block-remus.o REMUS-OBJS += hashtable.o REMUS-OBJS += hashtable_itr.o diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile --- a/tools/blktap2/vhd/Makefile Sun Dec 18 02:29:42 2011 +0100 +++ b/tools/blktap2/vhd/Makefile Sun Dec 18 02:29:42 2011 +0100 @@ -23,6 +23,10 @@ endif LIBS := -Llib -lvhd +ifeq ($(CONFIG_UCLIBC),y) +LIBS += -liconv +endif + all: subdirs-all build build: $(IBIN)
Roger Pau Monne
2011-Dec-18 12:48 UTC
[PATCH 4 of 5] blktap2: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID 7bcb3a61ce8846f8e7834d14c460c0f4b4869222
# Parent c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
blktap2: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
blktap2 was using defines set by qemu, even when the qemu config file
is not included. Remove this checkings, and instead check if the file
has been included before defining the necessary macros.
The output error is:
bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
diff -r c0d5aa328f1a -r 7bcb3a61ce88 tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100
@@ -15,9 +15,7 @@
#define bswap_64(x) swap64(x)
#else
-#ifdef HAVE_BYTESWAP_H
-#include <byteswap.h>
-#else
+#ifndef _BYTESWAP_H
#define bswap_16(x) \
({ \
@@ -51,7 +49,7 @@
(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >>
56) )); \
})
-#endif /* !HAVE_BYTESWAP_H */
+#endif /* !_BYTESWAP_H */
static inline uint16_t bswap16(uint16_t x)
{
Roger Pau Monne
2011-Dec-18 12:48 UTC
[PATCH 5 of 5] libxl: fix link issue on uclibc when using yajl
# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1324171782 -3600 # Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59 # Parent 7bcb3a61ce8846f8e7834d14c460c0f4b4869222 libxl: fix link issue on uclibc when using yajl yajl makes use of the isnan isinf functions. On Glibc, these are provided by libc, but on uClibc you need to link with -lm (like the spec says), so ensure we do so. Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> diff -r 7bcb3a61ce88 -r 6780cbdfa64b tools/libxl/Makefile --- a/tools/libxl/Makefile Sun Dec 18 02:29:42 2011 +0100 +++ b/tools/libxl/Makefile Sun Dec 18 02:29:42 2011 +0100 @@ -24,6 +24,10 @@ LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLI LIBXLU_LIBS +XL_LIBS + +TESTIDL_LIBS + LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o ifeq ($(LIBXL_BLKTAP),y) LIBXL_OBJS-y += libxl_blktap2.o @@ -35,6 +39,12 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu LIBXL_LIBS += -lyajl +ifeq ($(CONFIG_UCLIBC),y) +LIBXL_LIBS += -lm +XL_LIBS += -lm +TESTIDL_LIBS += -lm +endif + LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ @@ -127,10 +137,10 @@ libxlutil.a: $(LIBXLU_OBJS) $(AR) rcs libxlutil.a $^ xl: $(XL_OBJS) libxlutil.so libxenlight.so - $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS) + $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(XL_LIBS) $(APPEND_LDFLAGS) testidl: testidl.o libxlutil.so libxenlight.so - $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS) + $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(TESTIDL_LIBS) $(APPEND_LDFLAGS) .PHONY: install install: all
Ian Campbell
2011-Dec-19 09:48 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:> # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1324171782 -3600 > # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b > # Parent b783e76e63a99c9d87fca4974492f60af99a2e7a > blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu > > blktap was using defines set by qemu, even when the qemu config file > is not included. Remove this checkings, and instead check if the file > has been included before defining the necessary macros. > > The output error is: > > In file included from block-qcow.c:37:0: > bswap.h:23:0: error: "bswap_16" redefined [-Werror] > /usr/include/byteswap.h:30:0: note: this is the location of the > previous definition > bswap.h:31:0: error: "bswap_32" redefined [-Werror] > /usr/include/byteswap.h:33:0: note: this is the location of the > previous definition > bswap.h:41:0: error: "bswap_64" redefined [-Werror] > /usr/include/byteswap.h:37:0: note: this is the location of the > previous definition > cc1: all warnings being treated as errors > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> > > diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h > --- a/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 > +++ b/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 > @@ -15,9 +15,7 @@ > #define bswap_64(x) swap64(x) > #else > > -#ifdef HAVE_BYTESWAP_H > -#include <byteswap.h> > -#else > +#ifndef _BYTESWAP_HThis is basically saying "if the user hasn''t already include byteswap.h" but it seems to rely on that header using the precise guard _BYTESWAP_H which I presume can differ across platforms. I don''t think this is a viable approach. Given that we have our own definitions of these things any why not just remove the ifdef and single the other #include of byteswap.h and always use the ones we defined? The other alternative is to remove our own version and always include byteswap.h. The right answer depends on how standardised byteswap.h is. It seems to be in glibc but is it in uclibc and the BSD libcs? I can''t find a definitive reference but it seems like it is specified by POSIX? Ian.> > #define bswap_16(x) \ > ({ \ > @@ -51,7 +49,7 @@ > (uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \ > }) > > -#endif /* !HAVE_BYTESWAP_H */ > +#endif /* !_BYTESWAP_H */ > > static inline uint16_t bswap16(uint16_t x) > { > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-19 09:54 UTC
Re: [PATCH 5 of 5] libxl: fix link issue on uclibc when using yajl
On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:> # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1324171782 -3600 > # Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59 > # Parent 7bcb3a61ce8846f8e7834d14c460c0f4b4869222 > libxl: fix link issue on uclibc when using yajl > > yajl makes use of the isnan isinf functions. On Glibc, these are > provided by libc, but on uClibc you need to link with -lm (like the > spec says), so ensure we do so.If libyajl needs those symbols then it should link against libm itself and not rely ion the application to do so. There should be no need for an application using liyajl to do this itself when linking dynamically. I suspect this is a bug in libyajl. (if adding -lm were correct then it would be better to just do it unconditionally) Ian.> > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> > > diff -r 7bcb3a61ce88 -r 6780cbdfa64b tools/libxl/Makefile > --- a/tools/libxl/Makefile Sun Dec 18 02:29:42 2011 +0100 > +++ b/tools/libxl/Makefile Sun Dec 18 02:29:42 2011 +0100 > @@ -24,6 +24,10 @@ LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLI > > LIBXLU_LIBS > > +XL_LIBS > + > +TESTIDL_LIBS > + > LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o > ifeq ($(LIBXL_BLKTAP),y) > LIBXL_OBJS-y += libxl_blktap2.o > @@ -35,6 +39,12 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu > > LIBXL_LIBS += -lyajl > > +ifeq ($(CONFIG_UCLIBC),y) > +LIBXL_LIBS += -lm > +XL_LIBS += -lm > +TESTIDL_LIBS += -lm > +endif > + > LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ > libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ > libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \ > @@ -127,10 +137,10 @@ libxlutil.a: $(LIBXLU_OBJS) > $(AR) rcs libxlutil.a $^ > > xl: $(XL_OBJS) libxlutil.so libxenlight.so > - $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS) > + $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(XL_LIBS) $(APPEND_LDFLAGS) > > testidl: testidl.o libxlutil.so libxenlight.so > - $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS) > + $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(TESTIDL_LIBS) $(APPEND_LDFLAGS) > > .PHONY: install > install: all > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
William Pitcock
2011-Dec-19 09:57 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
Hi, On Mon, Dec 19, 2011 at 3:48 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote: >> # HG changeset patch >> # User Roger Pau Monne <roger.pau@entel.upc.edu> >> # Date 1324171782 -3600 >> # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b >> # Parent b783e76e63a99c9d87fca4974492f60af99a2e7a >> blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu >> >> blktap was using defines set by qemu, even when the qemu config file >> is not included. Remove this checkings, and instead check if the file >> has been included before defining the necessary macros. >> >> The output error is: >> >> In file included from block-qcow.c:37:0: >> bswap.h:23:0: error: "bswap_16" redefined [-Werror] >> /usr/include/byteswap.h:30:0: note: this is the location of the >> previous definition >> bswap.h:31:0: error: "bswap_32" redefined [-Werror] >> /usr/include/byteswap.h:33:0: note: this is the location of the >> previous definition >> bswap.h:41:0: error: "bswap_64" redefined [-Werror] >> /usr/include/byteswap.h:37:0: note: this is the location of the >> previous definition >> cc1: all warnings being treated as errors >> >> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> >> >> diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h >> --- a/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 >> +++ b/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 >> @@ -15,9 +15,7 @@ >> #define bswap_64(x) swap64(x) >> #else >> >> -#ifdef HAVE_BYTESWAP_H >> -#include <byteswap.h> >> -#else >> +#ifndef _BYTESWAP_H > > This is basically saying "if the user hasn''t already include byteswap.h" > but it seems to rely on that header using the precise guard _BYTESWAP_H > which I presume can differ across platforms. I don''t think this is a > viable approach. > > Given that we have our own definitions of these things any why not just > remove the ifdef and single the other #include of byteswap.h and always > use the ones we defined? > > The other alternative is to remove our own version and always include > byteswap.h. > > The right answer depends on how standardised byteswap.h is. It seems to > be in glibc but is it in uclibc and the BSD libcs? I can''t find a > definitive reference but it seems like it is specified by POSIX?uClibc 0.9.32 and later have byteswap.h. Not sure about earlier versions. byteswap.h is a GNU-ism though, and not in any of the BSDs as a result. We should just ship these definitions directly in Xen and not depend on it. William
Roger Pau Monné
2011-Dec-19 09:58 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote: >> # HG changeset patch >> # User Roger Pau Monne <roger.pau@entel.upc.edu> >> # Date 1324171782 -3600 >> # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b >> # Parent b783e76e63a99c9d87fca4974492f60af99a2e7a >> blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu >> >> blktap was using defines set by qemu, even when the qemu config file >> is not included. Remove this checkings, and instead check if the file >> has been included before defining the necessary macros. >> >> The output error is: >> >> In file included from block-qcow.c:37:0: >> bswap.h:23:0: error: "bswap_16" redefined [-Werror] >> /usr/include/byteswap.h:30:0: note: this is the location of the >> previous definition >> bswap.h:31:0: error: "bswap_32" redefined [-Werror] >> /usr/include/byteswap.h:33:0: note: this is the location of the >> previous definition >> bswap.h:41:0: error: "bswap_64" redefined [-Werror] >> /usr/include/byteswap.h:37:0: note: this is the location of the >> previous definition >> cc1: all warnings being treated as errors >> >> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> >> >> diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h >> --- a/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 >> +++ b/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 >> @@ -15,9 +15,7 @@ >> #define bswap_64(x) swap64(x) >> #else >> >> -#ifdef HAVE_BYTESWAP_H >> -#include <byteswap.h> >> -#else >> +#ifndef _BYTESWAP_H > > This is basically saying "if the user hasn't already include byteswap.h" > but it seems to rely on that header using the precise guard _BYTESWAP_H > which I presume can differ across platforms. I don't think this is a > viable approach.From what I saw _BYTESWAP_H is defined in uclibc and glibc (Solaris and NetBSD have their own preprocessor logic, so this doesn't apply to them). It's just a safeguard that avoids redefining the macros if someone has included byteswap.h behind our backs.> Given that we have our own definitions of these things any why not just > remove the ifdef and single the other #include of byteswap.h and always > use the ones we defined? > > The other alternative is to remove our own version and always include > byteswap.h. > > The right answer depends on how standardised byteswap.h is. It seems to > be in glibc but is it in uclibc and the BSD libcs? I can't find a > definitive reference but it seems like it is specified by POSIX?The solutions I see are: * Check if byteswap.h has been included (this patch). * undef bswap_* functions and define our own. * Include byteswap.h. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-19 10:01 UTC
Re: [PATCH 5 of 5] libxl: fix link issue on uclibc when using yajl
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote: >> # HG changeset patch >> # User Roger Pau Monne <roger.pau@entel.upc.edu> >> # Date 1324171782 -3600 >> # Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59 >> # Parent 7bcb3a61ce8846f8e7834d14c460c0f4b4869222 >> libxl: fix link issue on uclibc when using yajl >> >> yajl makes use of the isnan isinf functions. On Glibc, these are >> provided by libc, but on uClibc you need to link with -lm (like the >> spec says), so ensure we do so. > > If libyajl needs those symbols then it should link against libm itself > and not rely ion the application to do so. There should be no need for > an application using liyajl to do this itself when linking dynamically.I've compiled yajl with -lm, but the same error comes up when compiling libxl if -lm is not added also. Will look into it deeply.> I suspect this is a bug in libyajl.Probably> (if adding -lm were correct then it would be better to just do it > unconditionally) > > Ian._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-19 10:05 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:> # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1324171782 -3600 > # Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb > # Parent c54c326d6fdf26d311c872479b769b3a8cd560cf > blktap2: fix vhd compilation under uclibc > > blktap2 was not compiled succesfully under uclibc, with the following > error: > > gcc -o vhd-util vhd-util.o -Llib -lvhd > lib/libvhd.so: undefined reference to `libiconv_open'' > lib/libvhd.so: undefined reference to `libiconv_close'' > lib/libvhd.so: undefined reference to `libiconv'' > > This patchs add the flag -liconv when blktap2/vhd is compiled on > uclibc.Since it is libvhd which uses these symbols it should be libvhd and not the utilities which links against it. Can we not directly check for the need for libiconv instead of infering it from the use of uclibc? Does the standard say one way or the other if this library needs to be explicitly linked? If uclibc is using http://www.haible.de/bruno/packages-libiconv.html then http://stackoverflow.com/questions/4709178/how-do-i-link-glibcs-implementation-of-iconv suggests -DLIBICONV_PLUG which from looking at the source seems like it might work -- all seems a little bit backwards though. Ian.> > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> > > diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile > --- a/tools/blktap2/drivers/Makefile Sun Dec 18 02:29:42 2011 +0100 > +++ b/tools/blktap2/drivers/Makefile Sun Dec 18 02:29:42 2011 +0100 > @@ -24,6 +24,10 @@ endif > > VHDLIBS := -L$(LIBVHDDIR) -lvhd > > +ifeq ($(CONFIG_UCLIBC),y) > +VHDLIBS += -liconv > +endif > + > REMUS-OBJS := block-remus.o > REMUS-OBJS += hashtable.o > REMUS-OBJS += hashtable_itr.o > diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile > --- a/tools/blktap2/vhd/Makefile Sun Dec 18 02:29:42 2011 +0100 > +++ b/tools/blktap2/vhd/Makefile Sun Dec 18 02:29:42 2011 +0100 > @@ -23,6 +23,10 @@ endif > > LIBS := -Llib -lvhd > > +ifeq ($(CONFIG_UCLIBC),y) > +LIBS += -liconv > +endif > + > all: subdirs-all build > > build: $(IBIN) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
William Pitcock
2011-Dec-19 10:07 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
Hi, On Sun, Dec 18, 2011 at 6:48 AM, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:> # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1324171782 -3600 > # Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb > # Parent c54c326d6fdf26d311c872479b769b3a8cd560cf > blktap2: fix vhd compilation under uclibc > > blktap2 was not compiled succesfully under uclibc, with the following > error:This description is wrong; it is a linktime symbol binding error, not a compilation error.> > gcc -o vhd-util vhd-util.o -Llib -lvhd > lib/libvhd.so: undefined reference to `libiconv_open'' > lib/libvhd.so: undefined reference to `libiconv_close'' > lib/libvhd.so: undefined reference to `libiconv'' > > This patchs add the flag -liconv when blktap2/vhd is compiled on > uclibc. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> > > diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile > --- a/tools/blktap2/drivers/Makefile Sun Dec 18 02:29:42 2011 +0100 > +++ b/tools/blktap2/drivers/Makefile Sun Dec 18 02:29:42 2011 +0100 > @@ -24,6 +24,10 @@ endif > > VHDLIBS := -L$(LIBVHDDIR) -lvhd > > +ifeq ($(CONFIG_UCLIBC),y) > +VHDLIBS += -liconv > +endifI don''t like this really. I think it is wrong to imply that $(CONFIG_UCLIBC) needs -liconv, as it is possible to build uClibc with iconv support. The real check here should be if we are running with GNU libiconv I think. Which makes me wonder why CONFIG_UCLIBC is necessary at all.> + > REMUS-OBJS := block-remus.o > REMUS-OBJS += hashtable.o > REMUS-OBJS += hashtable_itr.o > diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile > --- a/tools/blktap2/vhd/Makefile Sun Dec 18 02:29:42 2011 +0100 > +++ b/tools/blktap2/vhd/Makefile Sun Dec 18 02:29:42 2011 +0100 > @@ -23,6 +23,10 @@ endif > > LIBS := -Llib -lvhd > > +ifeq ($(CONFIG_UCLIBC),y) > +LIBS += -liconv > +endif > + > all: subdirs-all build > > build: $(IBIN) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-19 10:08 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
On Mon, 2011-12-19 at 09:58 +0000, Roger Pau Monné wrote:> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > > On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote: > >> # HG changeset patch > >> # User Roger Pau Monne <roger.pau@entel.upc.edu> > >> # Date 1324171782 -3600 > >> # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b > >> # Parent b783e76e63a99c9d87fca4974492f60af99a2e7a > >> blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu > >> > >> blktap was using defines set by qemu, even when the qemu config file > >> is not included. Remove this checkings, and instead check if the file > >> has been included before defining the necessary macros. > >> > >> The output error is: > >> > >> In file included from block-qcow.c:37:0: > >> bswap.h:23:0: error: "bswap_16" redefined [-Werror] > >> /usr/include/byteswap.h:30:0: note: this is the location of the > >> previous definition > >> bswap.h:31:0: error: "bswap_32" redefined [-Werror] > >> /usr/include/byteswap.h:33:0: note: this is the location of the > >> previous definition > >> bswap.h:41:0: error: "bswap_64" redefined [-Werror] > >> /usr/include/byteswap.h:37:0: note: this is the location of the > >> previous definition > >> cc1: all warnings being treated as errors > >> > >> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> > >> > >> diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h > >> --- a/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 > >> +++ b/tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 > >> @@ -15,9 +15,7 @@ > >> #define bswap_64(x) swap64(x) > >> #else > >> > >> -#ifdef HAVE_BYTESWAP_H > >> -#include <byteswap.h> > >> -#else > >> +#ifndef _BYTESWAP_H > > > > This is basically saying "if the user hasn't already include byteswap.h" > > but it seems to rely on that header using the precise guard _BYTESWAP_H > > which I presume can differ across platforms. I don't think this is a > > viable approach. > > From what I saw _BYTESWAP_H is defined in uclibc and glibc (Solaris > and NetBSD have their own preprocessor logic, so this doesn't apply to > them). It's just a safeguard that avoids redefining the macros if > someone has included byteswap.h behind our backs.It's not an effective safeguard though.> > Given that we have our own definitions of these things any why not just > > remove the ifdef and single the other #include of byteswap.h and always > > use the ones we defined? > > > > The other alternative is to remove our own version and always include > > byteswap.h. > > > > The right answer depends on how standardised byteswap.h is. It seems to > > be in glibc but is it in uclibc and the BSD libcs? I can't find a > > definitive reference but it seems like it is specified by POSIX? > > The solutions I see are: > > * Check if byteswap.h has been included (this patch). > * undef bswap_* functions and define our own. > * Include byteswap.h.* Never include byteswap.h and use our own bswap_* functions which we already define. I think this is the correct option. No need to undef stuff. There is only one other include of byteswap.h in blktap. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, On Sun, Dec 18, 2011 at 6:48 AM, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:> # HG changeset patch > # User Roger Pau Monne <roger.pau@entel.upc.edu> > # Date 1324171782 -3600 > # Node ID c54c326d6fdf26d311c872479b769b3a8cd560cf > # Parent eed78eb655c40b0ac9af1b14c1cc03204f696b0b > build: detect uclibc > > Detect uclibc build environment and define CONFIG_UCLIBC accordingly. > > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu> > > diff -r eed78eb655c4 -r c54c326d6fdf Config.mk > --- a/Config.mk Sun Dec 18 02:29:42 2011 +0100 > +++ b/Config.mk Sun Dec 18 02:29:42 2011 +0100 > @@ -18,6 +18,8 @@ XEN_TARGET_ARCH ?= $(XEN_COMPILE_ARC > XEN_OS ?= $(shell uname -s) > > CONFIG_$(XEN_OS) := y > +CONFIG_UCLIBC := $(shell gcc -dumpmachine | grep -c uclibc \ > + | sed -e s/[^0]/y/ -e s/0/n/)I don''t like this approach as it introduces an explicit dependency on gcc just to find out if we''re on uclibc or not. Please find a different way to do this. Checking for /usr/include/bits/uClibc_config.h should be sufficient, e.g. $(shell test -f /usr/include/bits/uClibc_config.h && echo ''y'' || echo ''n'') This approach would be cleaner, please use it instead. William
Roger Pau Monné
2011-Dec-19 11:26 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> I think this is the correct option. No need to undef stuff. There is > only one other include of byteswap.h in blktap. >On uclibc, byteswap.h gets included by default, because _GNU_SOURCE implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which prevents the addition of _BSD_SOURCE.
Ian Campbell
2011-Dec-19 11:27 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
On Mon, 2011-12-19 at 11:26 +0000, Roger Pau Monné wrote:> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > > I think this is the correct option. No need to undef stuff. There is > > only one other include of byteswap.h in blktap. > > > > On uclibc, byteswap.h gets included by default, because _GNU_SOURCE > implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which > prevents the addition of _BSD_SOURCE.What path of includes leads to the inclusion of byteswap.h? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-19 11:28 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> On Mon, 2011-12-19 at 11:26 +0000, Roger Pau Monné wrote: >> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: >> > I think this is the correct option. No need to undef stuff. There is >> > only one other include of byteswap.h in blktap. >> > >> >> On uclibc, byteswap.h gets included by default, because _GNU_SOURCE >> implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which >> prevents the addition of _BSD_SOURCE. > > What path of includes leads to the inclusion of byteswap.h?This one: stdlib.h -> sys/types.h -> endian.h -> (becasue __USE_BSD is defined) byteswap.h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-19 11:38 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
On Mon, 2011-12-19 at 11:28 +0000, Roger Pau Monné wrote:> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > > On Mon, 2011-12-19 at 11:26 +0000, Roger Pau Monné wrote: > >> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > >> > I think this is the correct option. No need to undef stuff. There is > >> > only one other include of byteswap.h in blktap. > >> > > >> > >> On uclibc, byteswap.h gets included by default, because _GNU_SOURCE > >> implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which > >> prevents the addition of _BSD_SOURCE. > > > > What path of includes leads to the inclusion of byteswap.h? > > This one: > > stdlib.h -> sys/types.h -> endian.h -> (becasue __USE_BSD is defined) byteswap.hHrm :-/ So on the flip side which platforms don't have this header at all? William suggested BSD doesn't but the use of __USE_BSD seems to suggest otherwise? Does NetBSD have byteswap.h? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-19 11:46 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> On Mon, 2011-12-19 at 11:28 +0000, Roger Pau Monné wrote: >> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: >> > On Mon, 2011-12-19 at 11:26 +0000, Roger Pau Monné wrote: >> >> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: >> >> > I think this is the correct option. No need to undef stuff. There is >> >> > only one other include of byteswap.h in blktap. >> >> > >> >> >> >> On uclibc, byteswap.h gets included by default, because _GNU_SOURCE >> >> implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which >> >> prevents the addition of _BSD_SOURCE. >> > >> > What path of includes leads to the inclusion of byteswap.h? >> >> This one: >> >> stdlib.h -> sys/types.h -> endian.h -> (becasue __USE_BSD is defined) byteswap.h > > Hrm :-/ > > So on the flip side which platforms don't have this header at all? > > William suggested BSD doesn't but the use of __USE_BSD seems to suggest > otherwise? > > Does NetBSD have byteswap.h?Nope, but NetBSD has it's own preprocessor case: #if defined(__NetBSD__) #include <sys/endian.h> #include <sys/types.h> Doesn't have byteswap.h per se, but the functions are there. NetBSD and OpenBSD are covered, because they have their specific cases, so only Solaris and Linux are left to this case. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-19 11:49 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
On Mon, 2011-12-19 at 11:46 +0000, Roger Pau Monné wrote:> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > > On Mon, 2011-12-19 at 11:28 +0000, Roger Pau Monné wrote: > >> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > >> > On Mon, 2011-12-19 at 11:26 +0000, Roger Pau Monné wrote: > >> >> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > >> >> > I think this is the correct option. No need to undef stuff. There is > >> >> > only one other include of byteswap.h in blktap. > >> >> > > >> >> > >> >> On uclibc, byteswap.h gets included by default, because _GNU_SOURCE > >> >> implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which > >> >> prevents the addition of _BSD_SOURCE. > >> > > >> > What path of includes leads to the inclusion of byteswap.h? > >> > >> This one: > >> > >> stdlib.h -> sys/types.h -> endian.h -> (becasue __USE_BSD is defined) byteswap.h > > > > Hrm :-/ > > > > So on the flip side which platforms don't have this header at all? > > > > William suggested BSD doesn't but the use of __USE_BSD seems to suggest > > otherwise? > > > > Does NetBSD have byteswap.h? > > > Nope, but NetBSD has it's own preprocessor case: > > #if defined(__NetBSD__) > #include <sys/endian.h> > #include <sys/types.h> > > Doesn't have byteswap.h per se, but the functions are there. NetBSD > and OpenBSD are covered, because they have their specific cases, so > only Solaris and Linux are left to this case.Solaris isn't an issue these days. So, I think the approach used by tools/blktap2/include/libvhd.h should be used in tools/blktap2/drivers/bswap.h too. i.e. #include byteswap.h for Linux and remove the local definitions of the swap functions/macros. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-19 12:04 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> So, I think the approach used by tools/blktap2/include/libvhd.h should > be used in tools/blktap2/drivers/bswap.h too. i.e. #include byteswap.h > for Linux and remove the local definitions of the swap functions/macros.Ok, I''ve included endian.h and byteswap.h just like libvhd.h does.
Roger Pau Monné
2011-Dec-19 12:30 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
What''s strange is that libvhd (which uses iconv) compiles and links fine, but vhd-util that uses libvhd complains about undefined references to iconv, when vhd-util doesn''t use iconv.
Ian Campbell
2011-Dec-19 13:26 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
On Mon, 2011-12-19 at 12:30 +0000, Roger Pau Monné wrote:> What's strange is that libvhd (which uses iconv) compiles and links > fine,libvhd needs -liconv but it will compile and link without it fine. It is only when you try to link something against that library that the problem will manifest itself.> but vhd-util that uses libvhd complains about undefined > references to iconv, when vhd-util doesn't use iconv.Right. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-19 13:30 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> On Mon, 2011-12-19 at 12:30 +0000, Roger Pau Monné wrote: >> What's strange is that libvhd (which uses iconv) compiles and links >> fine, > > libvhd needs -liconv but it will compile and link without it fine. It is > only when you try to link something against that library that the > problem will manifest itself. > >> but vhd-util that uses libvhd complains about undefined >> references to iconv, when vhd-util doesn't use iconv. > > Right. > > Ian.I have a expression that checks for libiconv, but it will only detect it if ldconfig is present, if the system doesn't have ldconfig (NetBSD), libiconv will not be detected even if it is present: which ldconfig 2>&1 >/dev/null && (ldconfig -p | grep -q libiconv && echo 'y' || echo 'n') || echo 'n' _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-19 13:43 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
On Mon, 2011-12-19 at 13:30 +0000, Roger Pau Monné wrote:> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: > > On Mon, 2011-12-19 at 12:30 +0000, Roger Pau Monné wrote: > >> What's strange is that libvhd (which uses iconv) compiles and links > >> fine, > > > > libvhd needs -liconv but it will compile and link without it fine. It is > > only when you try to link something against that library that the > > problem will manifest itself. > > > >> but vhd-util that uses libvhd complains about undefined > >> references to iconv, when vhd-util doesn't use iconv. > > > > Right. > > > > Ian. > > I have a expression that checks for libiconv, but it will only detect > it if ldconfig is present, if the system doesn't have ldconfig > (NetBSD), libiconv will not be detected even if it is present: > > which ldconfig 2>&1 >/dev/null && (ldconfig -p | grep -q libiconv && > echo 'y' || echo 'n') || echo 'n'Urgh, surely there's a better way! Perhaps grepping for LIBICONV_PLUG or libiconv_open or something unique in iconv.h would be better? BTW did you try defining LIBICONV_PLUG? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-19 14:43 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:> On Mon, 2011-12-19 at 13:30 +0000, Roger Pau Monné wrote: >> 2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>: >> > On Mon, 2011-12-19 at 12:30 +0000, Roger Pau Monné wrote: >> >> What's strange is that libvhd (which uses iconv) compiles and links >> >> fine, >> > >> > libvhd needs -liconv but it will compile and link without it fine. It is >> > only when you try to link something against that library that the >> > problem will manifest itself. >> > >> >> but vhd-util that uses libvhd complains about undefined >> >> references to iconv, when vhd-util doesn't use iconv. >> > >> > Right. >> > >> > Ian. >> >> I have a expression that checks for libiconv, but it will only detect >> it if ldconfig is present, if the system doesn't have ldconfig >> (NetBSD), libiconv will not be detected even if it is present: >> >> which ldconfig 2>&1 >/dev/null && (ldconfig -p | grep -q libiconv && >> echo 'y' || echo 'n') || echo 'n' > > Urgh, surely there's a better way! > > Perhaps grepping for LIBICONV_PLUG or libiconv_open or something unique > in iconv.h would be better?grep -q LIBICONV_PLUG /usr/include/iconv.h && echo 'y' || echo 'n' Does the job, but I don't know how reliable it is to rely on LIBICONV_PLUG. Tested on NetBSD, Debian 6.0.3 and Alpine 2.3.2 with success.> BTW did you try defining LIBICONV_PLUG?LIBICONV_PLUG should not be defined, because that prevents iconv from defining iconv_open, iconv_close... as alias to libiconv_open, libiconv_close... and libvhd uses this functions. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-20 17:55 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
Hello, I''ve added -liconv to blktap2/vhd/lib, and succesfully compiled and linked the library. The output from ldd libvhd.so shows: checking sub-depends for ''/lib/libuuid.so.1'' checking sub-depends for ''/usr/lib/libiconv.so.2'' checking sub-depends for ''/lib/libc.so.0.9.32'' checking sub-depends for ''/lib/ld64-uClibc.so.0.9.32'' libuuid.so.1 => /lib/libuuid.so.1 (0x00000000) libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00000000) libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x00000000) ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x00000000) not a dynamic executable Then I''ve compiled and linked vhd tools (vhd-util and vhd-update) without -liconv, since vhd tools doesn''t use any iconv functions. They compile fine, but when I try to execute them I get the following error: vhd-util: symbol ''libiconv_open'': can''t resolve symbol If I do a ldd of vhd-util: libvhd.so.1.0 => /usr/lib/libvhd.so.1.0 (0x7699efaf4000) libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x7699ef88c000) libuuid.so.1 => /lib/libuuid.so.1 (0x7699ef689000) ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x7699efd10000) How come libiconv is not linked to the application if libvhd is? And what''s most strange, why is the link to libuuid keep, but not the one to libiconv? Thanks, Roger.
Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 5] build: detect
uclibc"):> build: detect uclibc
>
> Detect uclibc build environment and define CONFIG_UCLIBC accordingly.
I''m not a huge fan of this configuration approach, particularly for a
variant libc. Rather, we should use portable constructs.
Ian.
2011/12/20 Ian Jackson <Ian.Jackson@eu.citrix.com>:> Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 5] build: detect uclibc"): >> build: detect uclibc >> >> Detect uclibc build environment and define CONFIG_UCLIBC accordingly. > > I'm not a huge fan of this configuration approach, particularly for a > variant libc. Rather, we should use portable constructs.That will be gone on the new series I'm working on, the only thing I'm missing is the libiconv stuff that's driving me nuts. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 2 of 5] build: detect
uclibc"):> That will be gone on the new series I''m working on,
Great.
> the only thing I''m missing is the libiconv stuff that''s
driving me nuts.
Good luck ...
Ian.
Roger Pau Monné
2011-Dec-21 09:40 UTC
Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it''s defined by qemu
2011/12/19 Roger Pau Monné <roger.pau@entel.upc.edu>:> Ok, I've included endian.h and byteswap.h just like libvhd.h does.I don't think endian.h is necessary at all, so I've just included byteswap.h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-21 10:01 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
On Tue, 2011-12-20 at 17:55 +0000, Roger Pau Monné wrote:> Hello, > > I've added -liconv to blktap2/vhd/lib, and succesfully compiled and > linked the library. The output from ldd libvhd.so shows: > > checking sub-depends for '/lib/libuuid.so.1' > checking sub-depends for '/usr/lib/libiconv.so.2' > checking sub-depends for '/lib/libc.so.0.9.32' > checking sub-depends for '/lib/ld64-uClibc.so.0.9.32' > libuuid.so.1 => /lib/libuuid.so.1 (0x00000000) > libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00000000) > libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x00000000) > ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x00000000) > not a dynamic executable > > Then I've compiled and linked vhd tools (vhd-util and vhd-update) > without -liconv, since vhd tools doesn't use any iconv functions. They > compile fine, but when I try to execute them I get the following > error: > > vhd-util: symbol 'libiconv_open': can't resolve symbol > > If I do a ldd of vhd-util: > > libvhd.so.1.0 => /usr/lib/libvhd.so.1.0 (0x7699efaf4000) > libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x7699ef88c000) > libuuid.so.1 => /lib/libuuid.so.1 (0x7699ef689000) > ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x7699efd10000) > > How come libiconv is not linked to the application if libvhd is?Can you post the complete link line for each stage? Are you sure that /usr/lib/libvhd.so.1.0 is the same one you just built and linked against? Is there a chance you have linked against something in the build directory which did not get properly installed? Running objdump -p <object> | egrep NEEDED\|SONAME for the library (both build dir and installed copies) and binary would be interesting. It seems like either this is a bug in uClibc's dynamic linker or my expectation of how these sorts of transitive library dependencies work has been set too high by glibc...> And > what's most strange, why is the link to libuuid keep, but not the one > to libiconv?Yes, that is strange. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Roger Pau Monné
2011-Dec-21 10:15 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
2011/12/21 Ian Campbell <Ian.Campbell@citrix.com>:> On Tue, 2011-12-20 at 17:55 +0000, Roger Pau Monné wrote: >> Hello, >> >> I've added -liconv to blktap2/vhd/lib, and succesfully compiled and >> linked the library. The output from ldd libvhd.so shows: >> >> checking sub-depends for '/lib/libuuid.so.1' >> checking sub-depends for '/usr/lib/libiconv.so.2' >> checking sub-depends for '/lib/libc.so.0.9.32' >> checking sub-depends for '/lib/ld64-uClibc.so.0.9.32' >> libuuid.so.1 => /lib/libuuid.so.1 (0x00000000) >> libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00000000) >> libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x00000000) >> ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x00000000) >> not a dynamic executable >> >> Then I've compiled and linked vhd tools (vhd-util and vhd-update) >> without -liconv, since vhd tools doesn't use any iconv functions. They >> compile fine, but when I try to execute them I get the following >> error: >> >> vhd-util: symbol 'libiconv_open': can't resolve symbol >> >> If I do a ldd of vhd-util: >> >> libvhd.so.1.0 => /usr/lib/libvhd.so.1.0 (0x7699efaf4000) >> libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x7699ef88c000) >> libuuid.so.1 => /lib/libuuid.so.1 (0x7699ef689000) >> ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x7699efd10000) >> >> How come libiconv is not linked to the application if libvhd is? > > Can you post the complete link line for each stage? > > Are you sure that /usr/lib/libvhd.so.1.0 is the same one you just built > and linked against? Is there a chance you have linked against something > in the build directory which did not get properly installed?Sorry, I'm just stupid, today I've realized what the problem was. It was linked against and old /usr/lib/libvhd.so which was not compiled with -liconv.> Running > objdump -p <object> | egrep NEEDED\|SONAME > for the library (both build dir and installed copies) and binary would > be interesting. > > It seems like either this is a bug in uClibc's dynamic linker or my > expectation of how these sorts of transitive library dependencies work > has been set too high by glibc... > >> And >> what's most strange, why is the link to libuuid keep, but not the one >> to libiconv? > > Yes, that is strange.I still don't get the libuuid thing, but it works just fine now.> Ian. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Dec-21 10:28 UTC
Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
On Wed, 2011-12-21 at 10:15 +0000, Roger Pau Monné wrote:> 2011/12/21 Ian Campbell <Ian.Campbell@citrix.com>: > > On Tue, 2011-12-20 at 17:55 +0000, Roger Pau Monné wrote: > >> Hello, > >> > >> I've added -liconv to blktap2/vhd/lib, and succesfully compiled and > >> linked the library. The output from ldd libvhd.so shows: > >> > >> checking sub-depends for '/lib/libuuid.so.1' > >> checking sub-depends for '/usr/lib/libiconv.so.2' > >> checking sub-depends for '/lib/libc.so.0.9.32' > >> checking sub-depends for '/lib/ld64-uClibc.so.0.9.32' > >> libuuid.so.1 => /lib/libuuid.so.1 (0x00000000) > >> libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00000000) > >> libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x00000000) > >> ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x00000000) > >> not a dynamic executable > >> > >> Then I've compiled and linked vhd tools (vhd-util and vhd-update) > >> without -liconv, since vhd tools doesn't use any iconv functions. They > >> compile fine, but when I try to execute them I get the following > >> error: > >> > >> vhd-util: symbol 'libiconv_open': can't resolve symbol > >> > >> If I do a ldd of vhd-util: > >> > >> libvhd.so.1.0 => /usr/lib/libvhd.so.1.0 (0x7699efaf4000) > >> libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x7699ef88c000) > >> libuuid.so.1 => /lib/libuuid.so.1 (0x7699ef689000) > >> ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x7699efd10000) > >> > >> How come libiconv is not linked to the application if libvhd is? > > > > Can you post the complete link line for each stage? > > > > Are you sure that /usr/lib/libvhd.so.1.0 is the same one you just built > > and linked against? Is there a chance you have linked against something > > in the build directory which did not get properly installed? > > Sorry, I'm just stupid, today I've realized what the problem was. It > was linked against and old /usr/lib/libvhd.so which was not compiled > with -liconv.Great.> > > Running > > objdump -p <object> | egrep NEEDED\|SONAME > > for the library (both build dir and installed copies) and binary would > > be interesting. > > > > It seems like either this is a bug in uClibc's dynamic linker or my > > expectation of how these sorts of transitive library dependencies work > > has been set too high by glibc... > > > >> And > >> what's most strange, why is the link to libuuid keep, but not the one > >> to libiconv? > > > > Yes, that is strange. > > I still don't get the libuuid thing, but it works just fine now.Presumably the old libvhd.so not compiled against -liconv _was_ compiled with -luuid. Ian.> > > Ian. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel