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 >>> wrote: >>>> On Fri, Sep 13, 2013 at 2:21 PM, Richard Purdie >>>> 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 >>>>>> wrote: >>>>>>> On Fri, Sep 13, 2013 at 11:08 AM, Hans Beckérus >>>>>>> wrote: >>>>>>>> On Fri, Sep 13, 2013 at 11:01 AM, Hans Beckérus >>>>>>>> wrote: >>>>>>>>> On Fri, Sep 13, 2013 at 10:52 AM, Richard Purdie >>>>>>>>> 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 >>>>>>>>>>> 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 >>>>> >>>>> >>> >>> >