[PATCH 0 of 5] build: various fixes for building with uclibc

[PATCH 0 of 5] build: various fixes for building with uclibc

[Roger Pau Monne]

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.

[PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monne]

# 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)
 {

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Ian Campbell]

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?

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[William Pitcock]

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monné]

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Ian Campbell]

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monné]

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.

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Ian Campbell]

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monné]

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Ian Campbell]

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?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monné]

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Ian Campbell]

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

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monné]

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.

Re: [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monné]

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

[PATCH 2 of 5] build: detect uclibc

[Roger Pau Monne]

# 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

Re: [PATCH 2 of 5] build: detect uclibc

[William Pitcock]

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

Re: [PATCH 2 of 5] build: detect uclibc

[Ian Jackson]

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.

Re: [PATCH 2 of 5] build: detect uclibc

[Roger Pau Monné]

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

Re: [PATCH 2 of 5] build: detect uclibc

[Ian Jackson]

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.

[PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Roger Pau Monne]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Ian Campbell]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[William Pitcock]

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
> +endif

I 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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Roger Pau Monné]

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.

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Ian Campbell]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Roger Pau Monné]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Ian Campbell]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Roger Pau Monné]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Roger Pau Monné]

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.

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Ian Campbell]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Roger Pau Monné]

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

Re: [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Ian Campbell]

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

[PATCH 4 of 5] blktap2: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

[Roger Pau Monne]

# 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)
 {

[PATCH 5 of 5] libxl: fix link issue on uclibc when using yajl

[Roger Pau Monne]

# 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

Re: [PATCH 5 of 5] libxl: fix link issue on uclibc when using yajl

[Ian Campbell]

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

Re: [PATCH 5 of 5] libxl: fix link issue on uclibc when using yajl

[Roger Pau Monné]

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