Build chokes hard on pkgconfig-native with the following: #error GNU libiconv not in use but included iconv.h is from libiconv Doing the trick from uClibc specifcation builds with it makes it "happy" but it fails later in the process on other native parts, expecting to have GNU libiconv present when you do it.
Can you provide a little more information about about your setup? I believe this should work. This should be linking against the host system's libiconv directly. Can you provide more details please.
Not a problem...what info would you like past this: Xubuntu 14.04 Base minimal setup that Bitbake calls for typically. 32Gb of RAM 1Tb of HD Fresh pull of Poky from GIT and then checked out to Daisy. Has Poky. Has meta-openembedded for a few pieces I need from it recipe-wise, also checked to Daisy. Has meta-raspberrypi in right at the moment because I'm trying to make some tuned builds for it for some projects, also checked to Daisy. It kind of blindsided me, really. Been doing this sort of thing for a while under OE and convinced clients (though this is my pet stuff) to move over to it for Distribution build. Want to know if it's fixable for Daisy or if I should wait for the release at the end of the month.
Paste the build configuration thats in cooker logs on top, thats concise and have lot of needed info. Do you build for uclibc ? do you have libiconv installed on your box ? or libiconv-native staged in build tree ?
I just did a new setup with this configuration: Build Configuration: BB_VERSION = "1.22.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-14.04" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "1.6.1" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" and ran: $ bitbake pkgconfig-native and it did not fail
Hi Frank, is this something you can reproduce in more than 1 setup?
Sorry about the delay on things...and I still owe some stuff even after this update. (Heh...consequence of showing horses and the Nationals for your breed coming up at the same time as the issue...) No configs yet...need to get time tonight for this. Pulled Dizzy fresh from Git and just configured for and tried to build minimal. Does the same thing on my system as reported on Daisy. I'll get the dumps from both as requested shortly.
Thanks Frank! I'll be waiting for your logs
Looks like leakage from the host in a way that you just simply can't avoid unless you're bootstrapping more than we're doing right at the moment. I went digging and found the problem and it was endemic to my configuration. OE was finding a copy of iconv.h that I didn't even know was on the system from a previous project in /usr/local/include (sigh...) I'll leave it open for the team to decide if they want to turn this into a feature request to bootstrap more of the native side of things to avoid problems, document this gotcha somewhere in a Wiki so that people can find this boo-boo, or the like.
I can't see a NEEDINFO question on this. I have changed the status to ACCEPTED. Please update with a question and switch back to NEEDINFO if a question still exists.
Yup, I was able to reproduce this by building and installing libiconv locally on my build machine, so this is a problem in master back to daisy.
There is not a way to check for all the variety of interesting things could be installed /usr/local and cause failures, as the submitter found the issue and there is a work around, we can add some documentation.
Hi, Here is a first attempt at a FAQ entry to try and describe this issue. I tried to generalize it a bit but still have the key 'iconv.h' and 'libiconv' terms in there for searchability. I am sure this needs some correction and tweaking. Please look at FAQ entry 14.16 at http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#faq and give me some feedback. Thanks, Scott
Hi, I made some quick updates based on feedback from Saul. Please look at FAQ entry 14.16 at http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#faq and give me some feedback. Thanks, Scott