build: various fixes for building with uclibc

# HG changeset patch
# User Roger Pau Monne <[email protected]>
# 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 <[email protected]>

diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h

tools/blktap/drivers/bswap.h +1 -1

 #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
[email protected]
http://lists.xensource.com/xen-devel

Quoted 31 lines · Roger Pau Monne

# HG changeset patch
# User Roger Pau Monne <[email protected]>
# 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 <[email protected]>

diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h

tools/blktap/drivers/bswap.h    Sun Dec 18 02:29:42 2011 +0100 line 18

Quoted 7 lines

tools/blktap/drivers/bswap.h    Sun Dec 18 02:29:42 2011 +0100 +1 -3

@@ -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?

Quoted 34 lines

# HG changeset patch
# User Roger Pau Monne <[email protected]>
# 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 <[email protected]>

diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h

tools/blktap/drivers/bswap.h    Sun Dec 18 02:29:42 2011 +0100 +0 -0

@@ -15,9 +15,7 @@
  #define bswap_64(x) swap64(x)
  #else
 

tools/blktap/drivers/bswap.h    Sun Dec 18 02:29:42 2011 +0100 line 18

Quoted 4 lines

tools/blktap/drivers/bswap.h    Sun Dec 18 02:29:42 2011 +0100 +1 -3

-#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?

2011/12/19 Ian Campbell <[email protected]>:

Quoted 35 lines · Roger Pau Monne

Quoted 34 lines

# HG changeset patch
# User Roger Pau Monne <[email protected]>
# 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 <[email protected]>

diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h

tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 +0 -0

@@ -15,9 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 

Quoted 9 lines

tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 line 18

Quoted 4 lines

tools/blktap/drivers/bswap.h Sun Dec 18 02:29:42 2011 +0100 +1 -3

-#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.

Quoted 10 lines

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.

I think this is the correct option. No need to undef stuff. There is only one other include of byteswap.h in blktap.

2011/12/19 Ian Campbell <[email protected]>:

Quoted 3 lines

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.

Quoted 8 lines

2011/12/19 Ian Campbell <[email protected]>:

Quoted 3 lines

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?

2011/12/19 Ian Campbell <[email protected]>:

Quoted 10 lines · Roger Pau Monné

Quoted 8 lines

2011/12/19 Ian Campbell <[email protected]>:

Quoted 3 lines

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.

Quoted 1 line

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

Quoted 11 lines

2011/12/19 Ian Campbell <[email protected]>:

Quoted 10 lines · Roger Pau Monné

Quoted 8 lines

2011/12/19 Ian Campbell <[email protected]>:

Quoted 3 lines

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.

Quoted 5 lines

Quoted 1 line

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?

2011/12/19 Ian Campbell <[email protected]>:

Quoted 18 lines · Roger Pau Monné

Quoted 11 lines

2011/12/19 Ian Campbell <[email protected]>:

Quoted 10 lines · Roger Pau Monné

Quoted 8 lines

2011/12/19 Ian Campbell <[email protected]>:

Quoted 3 lines

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.

Quoted 5 lines

Quoted 1 line

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

Quoted 8 lines

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.

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.

# HG changeset patch
# User Roger Pau Monne <[email protected]> # 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 <[email protected]>

diff -r eed78eb655c4 -r c54c326d6fdf Config.mk

Config.mk Sun Dec 18 02:29:42 2011 +0100 +0 -0

@@ -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/)

build: detect uclibc

Detect uclibc build environment and define CONFIG_UCLIBC accordingly.

Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 5] build: detect uclibc"):

Quoted 3 lines

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.

# HG changeset patch
# User Roger Pau Monne <[email protected]> # 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 <[email protected]>

diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile

tools/blktap2/drivers/Makefile +4 -0

@@ -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

tools/blktap2/vhd/Makefile +4 -0

@@ -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
[email protected]
http://lists.xensource.com/xen-devel

# HG changeset patch
# User Roger Pau Monne <[email protected]> # 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 <[email protected]>

diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile

tools/blktap2/drivers/Makefile    Sun Dec 18 02:29:42 2011 +0100 +0 -0

@@ -24,6 +24,10 @@ endif
 

 VHDLIBS    := -L$(LIBVHDDIR) -lvhd

+
 REMUS-OBJS  := block-remus.o
 REMUS-OBJS  += hashtable.o
 REMUS-OBJS  += hashtable_itr.o
diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile

tools/blktap2/vhd/Makefile        Sun Dec 18 02:29:42 2011 +0100 +0 -0

@@ -23,6 +23,10 @@ endif
 

 LIBS              := -Llib -lvhd

tools/blktap2/vhd/Makefile        Sun Dec 18 02:29:42 2011 +0100 +4 -0

+ifeq ($(CONFIG_UCLIBC),y)
+LIBS              += -liconv
+endif
+

 all: subdirs-all build

 build: $(IBIN)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

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.

Quoted 2 lines

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.

Quoted 2 lines

 but vhd-util that uses libvhd complains about undefined references to iconv, when vhd-util doesn't use iconv.

Right.

Ian.

2011/12/19 Ian Campbell <[email protected]>:

Quoted 13 lines · Roger Pau Monné

Quoted 2 lines

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.

Quoted 2 lines

but vhd-util that uses libvhd complains about undefined
references to iconv, when vhd-util doesn't use iconv.

Right.

Quoted 1 line

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'

Quoted 20 lines

2011/12/19 Ian Campbell <[email protected]>:

Quoted 8 lines · Roger Pau Monné

Quoted 2 lines

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.

Quoted 6 lines

Quoted 2 lines

 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:

Quoted 2 lines

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?

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?

Quoted 29 lines

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)

Quoted 1 line

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...

Quoted 3 lines

 And
what's most strange, why is the link to libuuid keep, but not the one to libiconv?

Yes, that is strange.

Ian.

2011/12/21 Ian Campbell <[email protected]>:

Quoted 34 lines · Roger Pau Monné

Quoted 22 lines

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

Quoted 8 lines

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?

Quoted 3 lines

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.

Quoted 10 lines

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...

Quoted 5 lines

Quoted 3 lines

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.

Quoted 3 lines

Ian.

# HG changeset patch
# User Roger Pau Monne <[email protected]> # 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 <[email protected]>

diff -r 7bcb3a61ce88 -r 6780cbdfa64b tools/libxl/Makefile

tools/libxl/Makefile +12 -2

@@ -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
[email protected]
http://lists.xensource.com/xen-devel

Quoted 7 lines

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1324171782 -3600
# Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59 # Parent  7bcb3a61ce8846f8e7834d14c460c0f4b4869222
libxl: fix link issue on uclibc when using yajl

Quoted 3 lines

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.