<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2013-09-13 7:49, Saul Wold wrote:<br>
</div>
<blockquote cite="mid:52335040.101@linux.intel.com" type="cite">On
09/13/2013 06:29 AM, Hans Beckérus wrote:
<br>
<blockquote type="cite">Hmm. Now suddenly I got an error on my
current world build of
<br>
util-linux-native package. Is this something that is a known
issue?
<br>
Provided that the sysroot is correct (which I assume) this is
because
<br>
of the local version of udev on my build host. So, is this
perhaps one
<br>
of the reasons why some hosts distros are not certified in eg.
Yocto?
<br>
<br>
</blockquote>
What is your host and host OS in this case?
<br>
<br>
</blockquote>
Its SUSE-LINUX-11<br>
<br>
<blockquote cite="mid:52335040.101@linux.intel.com" type="cite">Sau!
<br>
<blockquote type="cite">| In file included from
misc-utils/lsblk.c:46:0:
<br>
| /usr/include/libudev.h:28:2: error: #error "#define
<br>
LIBUDEV_I_KNOW_THE_API_IS_SUBJECT_TO_CHANGE is needed to use
this
<br>
experimental library version"
<br>
| In file included from misc-utils/findmnt.c:36:0:
<br>
| /usr/include/libudev.h:28:2: error: #error "#define
<br>
LIBUDEV_I_KNOW_THE_API_IS_SUBJECT_TO_CHANGE is needed to use
this
<br>
experimental library version"
<br>
</blockquote>
<br>
Have not see this before.
<br>
<br>
<br>
</blockquote>
Actually, I have ;) I sort of remembered seeing it before and I
found an old post I made in the Yocto mailing list.<br>
(wish we could easily link to mail threads)<br>
<br>
"<br>
Ok, I seem to have worked around this particular problem. I have new
ones but I post them separately ;)<br>
In this case it seems the <i>libudev</i> installed on my host is
too old and breaks the build.<br>
I solved it in my layer using a util-linux_2.22.2.bbappend file by
doing:<br>
<i> EXTRA_OECONF_append_class-native = " --without-udev"</i><br>
This is ok in my case since I will use mdev rather than udev. <br>
<br>
Hans<br>
"<br>
<br>
Thanks.<br>
Hans<br>
<br>
<br>
<blockquote cite="mid:52335040.101@linux.intel.com" type="cite">
<blockquote type="cite">| misc-utils/lsblk.c: In function
'get_udev_properties':
<br>
| misc-utils/lsblk.c:426:2: warning: implicit declaration of
function
<br>
'udev_device_new_from_subsystem_sysname'
<br>
[-Wimplicit-function-declaration]
<br>
| misc-utils/lsblk.c:426:2: warning: nested extern declaration
of
<br>
'udev_device_new_from_subsystem_sysname' [-Wnested-externs]
<br>
| misc-utils/lsblk.c:426:6: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/lsblk.c:430:3: warning: implicit declaration of
function
<br>
'udev_device_get_property_value'
[-Wimplicit-function-declaration]
<br>
| misc-utils/lsblk.c:430:3: warning: nested extern declaration
of
<br>
'udev_device_get_property_value' [-Wnested-externs]
<br>
| misc-utils/lsblk.c:430:13: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/lsblk.c:434:13: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/lsblk.c:438:13: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/lsblk.c:442:13: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/lsblk.c:444:13: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/lsblk.c:446:13: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/lsblk.c:448:13: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| make[2]: *** [misc-utils/lsblk-lsblk.o] Error 1
<br>
| make[2]: *** Waiting for unfinished jobs....
<br>
| misc-utils/findmnt.c: In function 'get_tag_from_udev':
<br>
| misc-utils/findmnt.c:386:2: warning: implicit declaration of
<br>
function 'udev_device_new_from_subsystem_sysname'
<br>
[-Wimplicit-function-declaration]
<br>
| misc-utils/findmnt.c:386:2: warning: nested extern declaration
of
<br>
'udev_device_new_from_subsystem_sysname' [-Wnested-externs]
<br>
| misc-utils/findmnt.c:386:6: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/findmnt.c:394:3: warning: implicit declaration of
<br>
function 'udev_device_get_property_value'
<br>
[-Wimplicit-function-declaration]
<br>
| misc-utils/findmnt.c:394:3: warning: nested extern declaration
of
<br>
'udev_device_get_property_value' [-Wnested-externs]
<br>
| misc-utils/findmnt.c:394:8: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/findmnt.c:397:8: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/findmnt.c:400:8: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| misc-utils/findmnt.c:403:8: warning: assignment makes pointer
from
<br>
integer without a cast [enabled by default]
<br>
| make[2]: *** [misc-utils/findmnt-findmnt.o] Error 1
<br>
<br>
<br>
<br>
On Fri, Sep 13, 2013 at 3:08 PM, Hans Beckérus
<a class="moz-txt-link-rfc2396E" href="mailto:hans.beckerus@gmail.com"><hans.beckerus@gmail.com></a> wrote:
<br>
<blockquote type="cite">On Fri, Sep 13, 2013 at 2:21 PM, Richard
Purdie
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:richard.purdie@linuxfoundation.org"><richard.purdie@linuxfoundation.org></a> wrote:
<br>
<blockquote type="cite">On Fri, 2013-09-13 at 14:14 +0200,
Hans Beckérus wrote:
<br>
<blockquote type="cite">On Fri, Sep 13, 2013 at 11:53 AM,
Hans Beckérus <a class="moz-txt-link-rfc2396E" href="mailto:hans.beckerus@gmail.com"><hans.beckerus@gmail.com></a> wrote:
<br>
<blockquote type="cite">On Fri, Sep 13, 2013 at 11:08 AM,
Hans Beckérus <a class="moz-txt-link-rfc2396E" href="mailto:hans.beckerus@gmail.com"><hans.beckerus@gmail.com></a> wrote:
<br>
<blockquote type="cite">On Fri, Sep 13, 2013 at 11:01
AM, Hans Beckérus <a class="moz-txt-link-rfc2396E" href="mailto:hans.beckerus@gmail.com"><hans.beckerus@gmail.com></a>
wrote:
<br>
<blockquote type="cite">On Fri, Sep 13, 2013 at 10:52
AM, Richard Purdie
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:richard.purdie@linuxfoundation.org"><richard.purdie@linuxfoundation.org></a> wrote:
<br>
<blockquote type="cite">On Fri, 2013-09-13 at 10:06
+0200, Hans Beckérus wrote:
<br>
<blockquote type="cite">On Fri, Sep 13, 2013 at
1:07 AM, Hans Beckerus
<a class="moz-txt-link-rfc2396E" href="mailto:hans.beckerus@gmail.com"><hans.beckerus@gmail.com></a> wrote:
<br>
<blockquote type="cite">On 2013-09-12 11:09,
Hans Beckerus wrote:
<br>
<blockquote type="cite">
<br>
On 2013-09-12 8:02, Hans Beckérus wrote:
<br>
<br>
</blockquote>
I now got a somewhat better picture of what is
going on. I know what is
<br>
failing, and why. But currently I have no
solution ready. Actually there are
<br>
some nasty traps to get caught in here :(. The
problem is actually as simple
<br>
as it is obvious. For all those native
packages that do work (this is a
<br>
unique problem for native packages using
libtool), they all seem to share a
<br>
common thing in their recipes:
<br>
<br>
EXTRA_OECONF += "
--with-libtool-sysroot=${STAGING_DIR_NATIVE}"
<br>
<br>
Great! This is the way to do it. But, what if
someone forgets to do this?
<br>
Well the answer is; it will most likely *not*
compile!
<br>
Since libtool now has been fixed to correctly
pick up the sysroot from the
<br>
compiler (using --print-sysroot) if
--with-libtool-sysroot is not specified
<br>
it will try to execute ${CC} --print-sysroot.
Bummer! ${CC} is most likely
<br>
simply set to 'gcc' for native packages. That
is, the local host compiler is
<br>
used.
<br>
The sysroot for that is of course "/". And it
should be. Otherwise it will
<br>
bring in the wrong set of header files and
libraries. But, there is another
<br>
problem here. We should not let libtool use
"/"! Because even if we use the
<br>
local host compiler for native packages, we
still use the oe-core upstream
<br>
version of libtool, and that does not like
using "/" as sysroot. If it does
<br>
everything becomes a mess. And that is exactly
what seems to happen now
<br>
after the patch. Before the patch libtool
rendered the SDK for libtool
<br>
enabled packages more or less useless. But, it
also saved us in the native
<br>
case. Because if --with-libtool-sysroot was
set, the path was used directly,
<br>
but if it was not set, lt_sysroot was also
kept unset. And here is the
<br>
spooky part again. Having lt_sysroot set to
nothing seems to work just as
<br>
well as setting it, provided it points to a
valid location!? This magic
<br>
however did not work for the SDK which
requires the sysroot to be resolved
<br>
correctly when not specified. So one
conclusion could be that, for native
<br>
packages, enforcement of
--with-libtool-sysroot is a possible way
forward.
<br>
Would this be safe? I think so, but I might
have overlooked something. I
<br>
can also see in config.log that "configure" is
fed with a lot of arguments,
<br>
even if EXTRA_OECONF is not specified. How is
this handled? How can I try to
<br>
force this in for all native packages. I
looked into native.bbclass but it
<br>
was not obvious to me how anything in there
actually ends up in arguments to
<br>
"configure". Any hints? There are still a lot
of gaps in my analysis ;) If
<br>
anyone feels like they can fill in the gaps,
please do.
<br>
<br>
<br>
</blockquote>
Now this is getting interesting. When I said
before I could reproduce
<br>
the problem in a world build I did not know that
it would actually
<br>
succeed later. On a different build server!! The
previous analysis
<br>
made is mostly true. But there is something
more. Why did it succeed
<br>
on one of my servers but not the other one? The
way to find out was to
<br>
compare what lt_sysroot is resolved to in both
cases. And there it
<br>
was. On the machine for which it works,
lt_sysroot is now picked up
<br>
from $CC --print-sysroot (due to the patch), but
the result is not
<br>
"/", it is unset! Which is the same behavior
that can be observed
<br>
without the libtool patch. So this is getting
even worse now. It is
<br>
gcc and host dependent. If gcc has been built
with a sysroot of "/" is
<br>
does not work since that will be picked up by
libtool, and is of
<br>
course wrong in our case. But if lt_sysroot is
kept unset, libtool
<br>
seems to be able to resolve a working default
using some other
<br>
(unknown) mechanism. That is why we have not
seen this problem before,
<br>
even though libtool actually did the wrong thing
before the patch. So
<br>
this leaves me with at least this question; is
it actually correct
<br>
that gcc has "/" as a compiled in sysroot on
some machines?
<br>
<br>
I then saw two possible solutions:
<br>
<br>
a) update the patch in libtool and if gcc
reports a single "/", skip
<br>
it and leave lt_sysroot unset.
<br>
b) consistency is the key. Let all native
packages force setting of a
<br>
proper lt_sysroot using --with-libtool-sysroot.
<br>
<br>
This is also when I found this in
autotools.bbclass
<br>
<br>
def append_libtool_sysroot(d):
<br>
# Only supply libtool sysroot option for
non-native packages
<br>
if not bb.data.inherits_class('native', d):
<br>
return
'--with-libtool-sysroot=${STAGING_DIR_HOST}'
<br>
return ""
<br>
<br>
I can somewhat understand the rationale behind
this. If building for
<br>
target you wish to point libtool to a proper
sysroot, and leaving it
<br>
unset for native seems like a good idea. But I
do not think that
<br>
really is the case. Even for native builds you
wish to point it to the
<br>
sysroot for the libtool actually being used. Not
to what the compiler
<br>
is pointing to, which is now the effect after
applying the libtool
<br>
patch. But which is actually what you want when
building from an
<br>
placement independent SDK toolchain for which
$CC is updated with a
<br>
proper --sysroot argument to gcc automatically
when the environment
<br>
script is sourced.
<br>
<br>
So my propasal now is to update
autotools.bbclass and for native
<br>
packages set
-with-libtool-sysroot=${STAGING_DIR_NATIVE}.
This should
<br>
cover all the corner cases and work in all
different combinations.
<br>
Again, consistency is the key. But I still need
to try it. Problem now
<br>
is that I need to wait until I have access to
the machine for which it
<br>
currently does not work to verify it properly.
<br>
<br>
Please advise. Does anyone object strongly to
this idea?
<br>
</blockquote>
<br>
Sadly its not the right thing to do. The purpose
of a sysroot option is
<br>
to say "compile and link against things in this
subdirectory, do not
<br>
look outside it". Our native binaries need to use
the system libc and
<br>
headers. They are therefore expected to look
outside STAGING_DIR_NATIVE
<br>
if they don't find what they need in there. Native
is really a special
<br>
hybrid case.
<br>
</blockquote>
</blockquote>
</blockquote>
Ok. Now I am with you :) Had to get some food and give
this a second
<br>
thought and I definitely agree.
<br>
Patching autotools.bbclass is not the right thing to do.
Most likely a
<br>
package wish to use the same sysroot as the compiler,
but sometimes it
<br>
does not. The "sometimes" here is the troll! Looking at
the libtool
<br>
package itself you can see that it is setting
<br>
-with-libtool-sysroot=${STAGING_DIR_NATIVE}. But that is
for that
<br>
package. Does not mean all of them wish to have it like
that. The real
<br>
bug here (the second one) seems to be that libtool
internals does not
<br>
handle a sysroot of "/" very well. It works fine if
sysroot is
<br>
undefined unless you really wish to point it to
somewhere special,
<br>
like in the case of the SDK for which you always wish to
point it to
<br>
the sysroot of the compiler and which is never going to
be "/".
<br>
I think, and I am up for other suggestions here, that
the only sane
<br>
fix (or workaround) is to trigger on the "/" and unset
lt_sysroot and
<br>
thus behave as it did before the patch was applied. This
fix should go
<br>
into libtool.m4. I can so far see no danger in doing
this and should
<br>
be bug-compatible with previous behavior. Also it will
make sure the
<br>
SDK works placement independent which was not the case
before the
<br>
patch was applied.
<br>
<br>
Thanks
<br>
Hans
<br>
.
<br>
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">Here I am not with you really.
Yes, the sysroot purpose is exactly what you say.
<br>
But, the sysroot for libtool *is* different. It has
nothing to do
<br>
really with what gcc is using, it just happens to be
the same on
<br>
standard systems. The purpose of the libtool sysroot
is to point to
<br>
libtools own sysroot, and this might not actually be
the same as the
<br>
compiler sysroot. As in our case. Since for native
packages, gcc and
<br>
libtool are executed in different context, libtool
*must* point to its
<br>
proper location for which it was built and that is
STAGING_DIR_NATIVE.
<br>
<br>
<blockquote type="cite">
<br>
So things should be working if "/" is specified as
the sysroot, or its
<br>
not specified at all. I think there are deeper
bugs in libtool we're
<br>
uncovering :(
<br>
<br>
When I first saw the patch, it looked like the
correct thing to be doing
<br>
but it now seems it may uncover further bugs which
are going to need to
<br>
get fixed before we can take this patch :(.
<br>
<br>
</blockquote>
I am testing this second patch now in a world build
and so far
<br>
everything looks good.
<br>
<br>
</blockquote>
Btw, what about the first alternative? Patching "/" to
nothing in
<br>
libtool. Having lt_sysroot unset seems to work ok.
<br>
I agree that patching autotools.bbclass might be
wrong. It seems my
<br>
patch in libtool only cause problems if gcc return
sysroot as "/", not
<br>
when it return nothing.
<br>
<br>
</blockquote>
</blockquote>
Guys, I need your feedback on this. Is it worth trying
this out and
<br>
testing a world build or should I simply drop it?
<br>
I have a new patch in libtool.m4 that now unsets
lt_sysroot if $CC
<br>
-print-sysroot returns "/". But I am in some sense
confused here since
<br>
on my bigger machine (for which gcc sets nothing) forcing
it to return
<br>
"/" and let lt_sysroot become=/ still works! So this also
seems to be
<br>
very host dependent. I need to try this out on the machine
that I
<br>
could really reproduce the build errors on.
<br>
</blockquote>
<br>
"/" and no sysroot should behave exactly the same. If they
do not, that
<br>
is a bug in libtool's code. I'd be fine with a check which
unsets it in
<br>
that case though. It masks another issue but we have to take
these one
<br>
at a time. I do believe this problem worth digging into.
Whether we can
<br>
get the fix in for the 1.5 release I'm not sure but we will
want to
<br>
address it in 1.6 regardless.
<br>
<br>
</blockquote>
Agree. Since all my patch did initially was to make sure gcc
was
<br>
queried when --with-libtool-sysroot was not specified this is
the only
<br>
possible reason I can think of that causes it to break like
this. And
<br>
there is only one side on this coin. The result before the
patch if a
<br>
sysroot *was* specified is the same now also after the patch.
I will
<br>
get back later with a status update on my world build. Will
probably
<br>
take all weekend since it is a simple dual-core ARM
mini-server :(
<br>
I am not really concerned about what release this is
targeting. I
<br>
consider this a workaround until I can dig deeper into what is
<br>
actually going wrong. My primary goal is to make sure that the
SDK
<br>
does not break as it did before when installed in different
paths. Of
<br>
course that must not affect legacy features so hopefully this
<br>
workaround eliminates that.
<br>
<br>
Thanks.
<br>
Hans
<br>
<br>
<br>
<blockquote type="cite">Cheers,
<br>
<br>
Richard
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>