Hi Joseph, Thanks for the clarification.
As far as I understand, I have restructured my recipe as you directed. However, when I bitbake -c populate_sdk core-image-full-cmdline, the sdk installer script still does not contain the LLVM/clang stuff. I'm hoping that you can see what I have done wrong. When I look for build artifacts, here's what I find for clang in the work directory. [jimr@krusty work]$ find . -name clang -ls |grep bin/clang 99906923 45428 -rwxr-xr-x 1 jimr jimr 46517960 Nov 19 12:00 ./spectra_ls-poky-linux/core-image-full-cmdline/1.0-r0/sdk/image/usr/bin/clang 94263147 45428 -rwxr-xr-x 2 jimr jimr 46517960 Nov 19 12:00 ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/packages-split/nativesdk-llvm/usr/bin/clang 94263147 45428 -rwxr-xr-x 2 jimr jimr 46517960 Nov 19 12:00 ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/package/usr/bin/clang 88904578 56380 -rwxr-xr-x 1 jimr jimr 57732373 Nov 19 11:51 ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/llvm-3.5.0/Release+Asserts/bin/clang 89415572 45432 -rwxr-xr-x 1 jimr jimr 46517960 Nov 19 12:00 ./x86_64-nativesdk-pokysdk-linux/nativesdk-llvm/3.5.0-r0/image/usr/bin/clang Finding the clang executable in /spectra_ls-poky-linux/core-image-full-cmdline/1.0-r0/sdk/image/usr/bin/clang would seem to suggest that it should be in the SDK, but it is not. Here are the recipes... ++ meta-spectra-ls-utils/recipes-devtools/llvm/llvm_3.5.0.bb: # # This recipe requires package perl-podlators to be installed on the build # workstation in order to work. # # TBD: look for yocto recipe for perl-podlators to be added to REQUIRE # for this recipe, to remove build machine dependency. # SUMMARY = "Clang c/c++ compiler with llvm framework" HOMEPAGE = "http://clang.llvm.org"; LICENSE = "NCSA" PR = "r0" LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d" SRC_URI = "file://llvm-3.5.0.tar.gz \ " SRC_URI[md5sum] = "e2dd127722ffb305c981d2a02687b4ff" SRC_URI[sha256sum] = "1badb762129feb7ced9484a7969c88cebab9b01b80b83002fc9690933cd7d0e0" #EXTRA_OECONF = "--config=Linux-yocto " INHIBIT_PACKAGE_DEBUG_SPLIT = "1" INSANE_SKIP_${PN} = "staticdev already-stripped" REQUIRES = "virtual/x86_64-pokysdk-linux-gcc-crosssdk" #everything installed under /usr/ hierarchy. FILES_${PN} = "/usr " inherit autotools do_configure () { ./configure --enable-optimized --enable-targets=x86,x86_64 --prefix=/usr } #EXTRA_OECONF="--enable-optimized --enable-targets=x86,x86_64 --prefix=/usr " BBCLASSEXTEND="native nativesdk" ++meta-spectra-ls-utils/recipes-devtools/llvm/packagegroup-llvm.bb LICENSE="NCSA" RDEPENDS_${PN}= "\ llvm \ " ++meta-spectra-ls-utils/recipes-devtools/llvm/packagegroup-nativesdk-llvm.bb LICENSE="NCSA" RDEPENDS_${PN}= "\ llvm \ " ++meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb # # Copyright (C) 2007 OpenedHand Ltd # SUMMARY = "Host packages for the standalone SDK or external toolchain" PR = "r12" LICENSE = "MIT" inherit packagegroup nativesdk PACKAGEGROUP_DISABLE_COMPLEMENTARY = "1" RDEPENDS_${PN} = "\ nativesdk-pkgconfig \ nativesdk-qemu \ nativesdk-qemu-helper \ nativesdk-pseudo \ nativesdk-unfs3 \ nativesdk-opkg \ nativesdk-libtool \ nativesdk-autoconf \ nativesdk-automake \ nativesdk-shadow \ nativesdk-makedevs \ nativesdk-smartpm \ nativesdk-llvm \ nativesdk-postinst-intercept \ " RDEPENDS_${PN}_darwin = "\ nativesdk-pkgconfig \ nativesdk-opkg \ nativesdk-libtool \ " Thank you very much in advance, -Jim- ________________________________ From: Joseph Andrew de la Peña [jdelap...@lexmark.com] Sent: Tuesday, November 18, 2014 8:52 PM To: Jim Rafert Cc: nick; yocto@yoctoproject.org Subject: Re: [yocto] New recipe for toolchain fails install, "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored." Good day Jim, Partly correct. To add more info, native is basically intended for host tools that should be placed into the native/host sysroot. Please don't disregard that. The clang compiler is built onto the target sysroot (i586) basically because of your recipe. The beauty of BBCLASSEXTEND is you don't need to name your recipe such as naitvesdk-<name>.bb or <name>-native.bb<http://native.bb> (when using inherit). By default, with no inherits or BBCLASSEXTEND, the recipe's packages files will be installed into the target sysroot, i586 (which you have experienced). Here's a quick recipe content for a tool that will be placed in native and nativesdk sysroot. ++ tool_1.0.bb<http://tool_1.0.bb> SUMMARY=tool LICENSE="" SRC_URI="" S="" # nothing fancy # FILES_${PN} already includes /usr/bin/* path. # Thus, all binaries installed in /usr/bin will be part of the primary package. BBCLASSEXTEND="native nativesdk" ++ packagegroup-<name>.bb (the specific packagegroup your package must be included) RDEPENDS_${PN} = "\ tool \ " ++ nativesdk-packagegroup-sdk-host.bb<http://nativesdk-packagegroup-sdk-host.bb> (by default, value of TOOLCHAIN_HOST_TASK, unless you specified otherwise) RDEPENDS_${PN} = "\ nativesdk-tool \ " Basically, that's just it. Thanks, Joseph On Sat, Nov 15, 2014 at 1:09 AM, Jim Rafert <j...@spectralogic.com<mailto:j...@spectralogic.com>> wrote: Hi Joseph, Thanks for the tips. I totally missed the pod2man problem, and never saw the BBCLASSEXTEND stuff in all my extensive googling. I researched the BBCLASSEXTENDS variable in the Yocto Project Reference Manual. >From what I read, I understand that adding "native" to BBCLASSEXTEND produces >executables that will run on the workstation that I use to build the recipe >with bitbake. This recipe could be REQUIREd by other recipes that depend upon >it to build. "nativesdk", on the other hand, should create executables that run on the SDKMACHINE architecture that is specified in my local.conf. Since I only need the Clang compiler to be available to SDK users for building applications outside of the bitbake environment, I think I need "nativesdk", but not "native". Is my understanding of this correct, or have I totally missed the point somewhere? Also, would it be more straighforward to just have my recipe inherit the nativesdk class? I added BBCLASSEXTEND="native nativesdk" to my recipe, and it still seems to be building in i586-poky-linux, which is not the SKDMACHINE architecture. Once again, thank you for your help. You have greatly advanced my understanding of building a recipe for the SDK. -Jim- ________________________________ From: Joseph Andrew de la Peña [jdelap...@lexmark.com<mailto:jdelap...@lexmark.com>] Sent: Friday, November 14, 2014 12:39 AM To: Jim Rafert Cc: nick; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> Subject: Re: [yocto] New recipe for toolchain fails install, "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored." Good day Jim, Seems to be that the main error is due to /bin/sh: pod2man: command not found. I think the tool is not present or any references to its path was not properly established. Also, for your expectation to be part of native and nativesdk, please add BBCLASSEXTEND = "native nativesdk" in your recipe. Thanks, - J On Fri, Nov 14, 2014 at 5:14 AM, Jim Rafert <j...@spectralogic.com<mailto:j...@spectralogic.com>> wrote: I noticed that a couple of my attachments didn't make it. So here they are. They're renamed with a .txt extension to slip them past the Argus eyes of MS Exchange. "These are not the droids you're looking for....Move along" -Jim- ________________________________________ From: nick [xerofo...@gmail.com<mailto:xerofo...@gmail.com>] Sent: Thursday, November 13, 2014 1:42 PM To: Jim Rafert; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> Subject: Re: [yocto] New recipe for toolchain fails install, "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored." Hey Jim, I had a stressful day with other things so I would like some time to unwind but I will try and help out later if that's OK. Nick On 14-11-13 03:13 PM, Jim Rafert wrote: > Hi folks, > > I'm trying to put together a recipe to include llvm and clang in the yocto > toolchain. My goal is to have the clang compiler available for application > development. I do not intend to compile the kernel or OS image with clang. > I have created a recipe and placed it in one of my added layers as follows: > > LICENSE = "NCSA" > PR = "r0" > LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d" > > SRC_URI = "file://llvm-3.5.0.tar.gz \ > " > SRC_URI[md5sum] = "e2dd127722ffb305c981d2a02687b4ff" > SRC_URI[sha256sum] = > "1badb762129feb7ced9484a7969c88cebab9b01b80b83002fc9690933cd7d0e0" > > EXTRA_OECONF = "--config=Linux-yocto " > > INHIBIT_PACKAGE_DEBUG_SPLIT = "1" > > INSANE_SKIP_${PN} = "already-stripped" > > #FILES_${PN} = "${libdir}/* /usr/bin " > inherit autotools > > do_configure () { > ./configure --enable-optimized --enable-targets=x86,x86_64 > --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu > } > > The recipe is copied from another recipe of mine that builds the POCO > libraries, so INSANE_SKIP_${PN} = "already-stripped" may not actually be > necessary, but was left in until I got the recipe running. > > I add the recipe to the toolchain by including it in TOOLCHAIN_HOST_TASK from > my local.conf, thus: > "TOOLCHAIN_HOST_TASK += " llvm " > > This gets the source unpacked, configures, and compiles, but do_install fails > with several instances of this message: "ERROR: ld.so: object 'libpseudo.so' > from LD_PRELOAD cannot be preloaded: ignored." > > Even though it doesn't install, the build products are in the work directory, > so I examined them. > > [jimr@krusty llvm-3.5.0]$ file > /home/jimr/tera/yocto/daisy/build/tmp/work/i586-poky-linux/llvm/3.5.0-r0/llvm-3.5.0/Release+Asserts/bin/clang > /home/jimr/tera/yocto/daisy/build/tmp/work/i586-poky-linux/llvm/3.5.0-r0/llvm-3.5.0/Release+Asserts/bin/clang: > ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked > (uses shared libs), for GNU/Linux 2.6.16, > BuildID[sha1]=0x96bd97125551d23e94bcbbc4e68b69b8db36def9, not stripped > > I was hoping that this would be built for the architecture specified in > local.conf for the toolchain, which is: SDKMACHINE ?= "x86_64" > > I think that this architecture mismatch may be the root of the problem with > the LD_PRELOAD of pseudo. I also would expect that the work directory would > be under x86_64-nativesdk-pokysdk-linux or x86_64-pokysdk-linux rather than > i586-poky-linux. > > Do any of you Yocto/OE/bitbake experts out there know what I might be doing > wrong, or not doing, that causes this problem? > > I have attached the output of the bitbake command, my local.conf file, the > recipe, and config.log and config.status from the work directory for your > viewing pleasure. > > Any help with this would be greatly appreciated. > > -Jim- > > > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
