[OE-core] [PATCH v4] libtool: fix resolve of lt_sysroot

Hans Beckerus hans.beckerus at gmail.com
Fri Sep 13 19:30:30 UTC 2013 

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

>>>> Thanks.
>>>> Hans
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> Richard
>>>>>
>>>>>
>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130913/5e03be17/attachment-0002.html>

More information about the Openembedded-core mailing list