| 00:04.44 | *** join/#oe KNERD|2 (~KNERD@24.175.253.226) |
| 00:11.13 | *** join/#oe KNERD (~KNERD@24.175.253.226) |
| 00:18.03 | *** join/#oe JackWinter (~jack@vodsl-10810.vo.lu) |
| 00:29.12 | *** join/#oe JackWinter (~jack@vodsl-10810.vo.lu) |
| 00:35.00 | *** join/#oe Shawn286 (~Shawn@unaffiliated/shawn156) |
| 00:41.46 | *** join/#oe uwe_ (~uwe_@dslb-088-064-212-101.pools.arcor-ip.net) |
| 01:07.28 | *** join/#oe Shawn287 (~Shawn@unaffiliated/shawn156) |
| 01:31.25 | *** join/#oe uwe_ (~uwe_@dslb-088-064-212-101.pools.arcor-ip.net) |
| 01:55.58 | *** join/#oe nitink1 (nitink@nat/intel/x-ritpyaijlyjtxchj) |
| 01:56.44 | *** join/#oe JackWinter_ (~jack@vodsl-10810.vo.lu) |
| 01:58.47 | *** join/#oe waynr (~waynr@ma.sdf.org) |
| 02:01.51 | *** join/#oe silviof1 (~silviof@unaffiliated/silviof) |
| 02:06.27 | *** join/#oe uwe_ (~uwe_@dslb-088-064-212-101.pools.arcor-ip.net) |
| 02:13.42 | *** join/#oe hbeck (~hbeck@38.114.125.83) |
| 02:13.47 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 02:16.59 | *** join/#oe darkschneider (~gab@93-32-59-224.ip32.fastwebnet.it) |
| 03:06.45 | *** join/#oe fusman (~fahad@110.93.212.98) |
| 03:28.42 | *** join/#oe fusman (~fahad@110.93.212.98) |
| 03:49.19 | *** join/#oe s3v3n62mm2 (~s3v3n62mm@p5DDC32CD.dip0.t-ipconnect.de) |
| 05:50.47 | *** join/#oe eren (~eren@unaffiliated/eren) |
| 05:54.35 | *** join/#oe eren (~eren@santralsozluk.com) |
| 05:54.35 | *** join/#oe eren (~eren@unaffiliated/eren) |
| 06:04.48 | *** join/#oe clio (~andrej@85.159.109.222) |
| 06:14.34 | *** join/#oe crxz0193 (~crxz0193@203.247.149.152) |
| 06:18.59 | *** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk) |
| 06:42.07 | *** join/#oe kbart (~KBart@213.197.143.19) |
| 06:48.19 | *** join/#oe kroon (~kroon@193.15.174.198) |
| 06:53.45 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 06:59.17 | kroon | otavio, ping |
| 07:04.37 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 07:04.54 | *** join/#oe GusBricker (~GusBricke@CPE-120-148-198-99.heum1.vic.bigpond.net.au) |
| 07:06.05 | kroon | I noticed that for a recipe that needs to download patches, these are placed directly under "downloads". Wouldn't there be a slight risk for filename clashes ? |
| 07:07.32 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 07:18.41 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:22.00 | *** join/#oe kristoffer (~kristoffe@c-e882e253.171-2-64736c10.cust.bredbandsbolaget.se) |
| 07:32.16 | *** join/#oe SorenHolm (~quassel@cpe.ge-0-2-0-950.faaqnqu1.dk.customer.tdc.net) |
| 07:34.57 | mago_ | when using buildroot, to configure packages, you usually describe the options in a "Config.in" file which is parsed by the package selection system. This allows the user to select not only to include a package or not, but also specifically configure the package. How do you achieve this in openembedded? Do I need to write a .bbappend file for each permutation of package configuration i want to use? |
| 07:37.18 | kroon | mago_, individual package configuration can be done in your distr.conf |
| 07:37.28 | kroon | distro.conf |
| 07:38.09 | mago_ | could you provide an example? |
| 07:38.26 | kroon | For qtbase I have 'PACKAGECONFIG_append_pn-qtbase = "accessibility"' |
| 07:39.15 | kroon | there is also PACKAGECONFIG_remove_pn-xxx |
| 07:40.38 | mago_ | i'm trying to reconfigure my kernel image format from an zImage to uImage. This is controlled by KERNEL_IMAGETYPE. I tried adding KERNEL_IMAGETYPE = "uImage" to my local.conf, should I instead rely on this PACKAGECONFIG for this? |
| 07:40.49 | mago_ | (KERNEL_IMAGETYPE in local.conf did not work by the way) |
| 07:41.45 | *** join/#oe GusBricker (~GusBricke@c122-107-239-5.mckinn3.vic.optusnet.com.au) |
| 07:42.37 | kroon | mago_, aah, nah, I'm getting your kernel doesn't use PACKAGECONFIG infrstructure. Which kernel is it ? |
| 07:42.43 | kroon | *betting* |
| 07:44.09 | *** join/#oe crxz0193 (~crxz0193@203.247.149.152) |
| 07:44.18 | kroon | mago_, if local.conf didnt work, maybe try setting it in a .bbappend file for your kernel |
| 07:49.16 | mago_ | kroon, im using the arago distro from TI. From what I can tell by inspecting the bitbake -g dependency list of my image (arago-console-image), it seems to use 'linux-ti-staging' from the meta-ti layer. I am unsure if this relies on "PACKAGECONFIG infrastructure". If I do however review the bitbake -e output, I can see that my KERNEL_IMAGETYPE assigned in local.conf gets overwritten by meta-ti/conf/machine/include/ti33x.inc:26 .. so I wonder how can |
| 07:49.17 | mago_ | <PROTECTED> |
| 07:50.07 | *** join/#oe ant_work (~ant__@host54-128-static.10-188-b.business.telecomitalia.it) |
| 08:11.18 | kroon | mago_, try using a .bbappend file for the kernel |
| 08:14.55 | *** join/#oe pompomJuice (~pompomJui@41.0.38.138) |
| 08:16.38 | *** join/#oe jbrianceau (uid10952@gateway/web/irccloud.com/x-awxrxxuxkhunjrzn) |
| 08:28.00 | *** join/#oe GusBricker (~GusBricke@c122-107-239-5.mckinn3.vic.optusnet.com.au) |
| 08:31.50 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 08:33.38 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 08:36.04 | mago_ | kroon, if my kernel recipe is called linux-ti-staging, should there not be a linux-ti-staging.bb somewhere, and my appendfile would be linux-ti-staging.bbappend? if a recipe PROVIDES linux-ti-staging but is named differently, how can I find it? and what should I call my appendfile? the PROVIDES name, or the original recipe filename.bbappend? |
| 08:36.37 | *** join/#oe tasslehoff (~tasslehof@77.40.182.98) |
| 08:46.16 | *** join/#oe Shawn286 (~Shawn@unaffiliated/shawn156) |
| 08:56.21 | pompomJuice | mago |
| 08:56.54 | *** join/#oe ao2 (~ao2@host248-124-dynamic.60-82-r.retail.telecomitalia.it) |
| 09:04.41 | kroon | mago_, I'm just guessing but try "cd meta-ti && find | grep linux-ti-staging" |
| 09:05.03 | kroon | mago_, kernel recipe might be something like linux-ti-staging_x.y.z.bb |
| 09:05.30 | kroon | mago_, name your .bbappend file linux-ti-staging_x.y.z.bbappend, or linux-ti-staging_%.bbappend |
| 09:08.44 | mago_ | ah, i see. From my dependency list, I can tell it is linux-ti-staging_3.12.bb which is in use. Out of curiosity, how does one select version of a recipe to use? |
| 09:09.23 | *** join/#oe roric (~roric@c-e69a70d5.013-177-67626713.cust.bredbandsbolaget.se) |
| 09:14.29 | mckoan | good morning |
| 09:25.49 | *** join/#oe stefan_schmidt (~stefan@p200300480937582DF2DEF1FFFE6228F7.dip0.t-ipconnect.de) |
| 09:29.21 | kroon | mago_, PREFERRED_VERSION_linux-ti-staging = "x.y.z" |
| 09:30.15 | *** join/#oe crxz0193 (~crxz0193@203.247.149.152) |
| 09:35.03 | *** join/#oe espiral (maze@unaffiliated/espiral) |
| 09:38.33 | mago_ | kroon, okay, so with a .bbappend file I was able to reconfigure the kernel recipe to output an uImage instead. This brings me back to my original question on how to re-configure packages (like buildroot does with menuconfig). It seems like a bit more work to do it with OE since you sometimes need to create these .bbappend files. What is this PACKAGECONFIG infrastructure, and is it being adopted by the majority of the community? |
| 09:47.42 | *** join/#oe khem (~khem@99-57-140-30.lightspeed.sntcca.sbcglobal.net) |
| 09:48.47 | tasslehoff | Trying to go from dylan to dora, and have trouble with gst-plugins-base-glib. log.do_rootfs calls it an Unknown package. |
| 09:52.36 | *** join/#oe phdeswer (~phdeswer@194.157.27.2) |
| 10:02.49 | *** join/#oe mihai (~mihai@80.97.15.150) |
| 10:04.48 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 10:06.50 | pompomJuice | aaargh! |
| 10:07.02 | pompomJuice | this bitbake should stop thinking for me sometimes |
| 10:07.50 | pompomJuice | anyone here know how to install an TI kernel module the correct way using bitbake etc? |
| 10:08.02 | pompomJuice | it's turning out to be the biggest mess |
| 10:08.13 | *** join/#oe JoFo (~Jean-Fran@host-213-213-229-139.brutele.be) |
| 10:08.15 | pompomJuice | why is this so difficult |
| 10:08.33 | pompomJuice | the previous guy |
| 10:08.38 | pompomJuice | with previous bitbake |
| 10:09.34 | pompomJuice | Copied some files generated by the kernel build process into the machine sysroots |
| 10:10.00 | pompomJuice | and then built the TI recipy |
| 10:10.03 | pompomJuice | no problems |
| 10:10.05 | pompomJuice | the new bitbake |
| 10:10.10 | pompomJuice | does not like this |
| 10:10.22 | pompomJuice | it sees that the files copied to sysroots are not ARM compatible |
| 10:10.25 | pompomJuice | then I get this error |
| 10:10.44 | pompomJuice | package/usr/src/kernel/scripts/mod/modpost: File format not recognized |
| 10:10.56 | pompomJuice | during the do_package stage |
| 10:11.00 | pompomJuice | more spesifically |
| 10:11.14 | pompomJuice | ERROR: Function failed: split_and_strip_files |
| 10:15.01 | pompomJuice | so how do you compile ti-syslink? |
| 10:15.10 | pompomJuice | it requires genksyms |
| 10:15.25 | mago_ | pompomJuice, is this from the meta-ti layer? |
| 10:15.36 | pompomJuice | its an onder syslink driver |
| 10:15.44 | pompomJuice | we copied the recipy |
| 10:15.51 | pompomJuice | or it looks copied |
| 10:16.13 | pompomJuice | we cannot upgrade to newer versions of syslink |
| 10:16.21 | pompomJuice | syslink is not backwards compat |
| 10:16.40 | pompomJuice | looks copied from meta-ti yes |
| 10:17.50 | pompomJuice | ti-syslink wont build |
| 10:17.56 | pompomJuice | it requires |
| 10:18.11 | pompomJuice | # Backup these files because we need if for ti-syslink |
| 10:18.11 | pompomJuice | <PROTECTED> |
| 10:18.11 | pompomJuice | <PROTECTED> |
| 10:18.11 | pompomJuice | <PROTECTED> |
| 10:18.17 | pompomJuice | so wtf |
| 10:18.40 | pompomJuice | how can it require something that only exists for a short time during the kernel tree build |
| 10:18.43 | pompomJuice | does not make any sense |
| 10:20.43 | pompomJuice | that backup part has been hacked into kernel.bbclass in the do_install section just before it does a make clean |
| 10:20.51 | pompomJuice | the problem is you cannot copy it back |
| 10:20.57 | pompomJuice | because bitbake is to clever |
| 10:21.25 | pompomJuice | it realizes those things do not run on arm |
| 10:21.33 | pompomJuice | hence QA errors |
| 10:21.34 | mago_ | it does not sound like a longterm solution either, to manually copy stuff into your sysroot? |
| 10:21.44 | pompomJuice | yea! |
| 10:21.46 | pompomJuice | only |
| 10:21.57 | pompomJuice | you could copy stuff into sysroots in denzil days |
| 10:21.59 | pompomJuice | not anymore |
| 10:22.16 | pompomJuice | do_package checks the binaries for machine compatability |
| 10:22.24 | pompomJuice | and absolutely refuses to put thse files in |
| 10:22.29 | pompomJuice | even if the human tells it otherwise |
| 10:22.32 | pompomJuice | it knows better and refuses |
| 10:22.54 | pompomJuice | now I am dead in the water |
| 10:23.39 | pompomJuice | there is one part in kernel.bbclass |
| 10:23.53 | mago_ | im not bitbake (or OE expert), but certainly there must be a way to deploy files which are not executables (and of the same architecture as target) |
| 10:23.54 | pompomJuice | inside the install part |
| 10:23.56 | pompomJuice | that says |
| 10:23.57 | pompomJuice | # Remove the following binaries which cause strip or arch QA errors |
| 10:23.57 | pompomJuice | <PROTECTED> |
| 10:24.04 | pompomJuice | the thing is |
| 10:24.05 | pompomJuice | I dont want to remove them |
| 10:24.21 | pompomJuice | I want them included because I am the human and I know better. Why is the computer telling me no |
| 10:24.28 | pompomJuice | I said do it |
| 10:24.42 | mago_ | if you want to change the behavior of kernel.bbclass, can't you override that particular function? |
| 10:24.44 | pompomJuice | so fucking frustrating |
| 10:25.10 | pompomJuice | the function that I need to change is the split_and_strip_files |
| 10:26.36 | mago_ | is it not possible to override that using a .bbappend file? |
| 10:26.44 | pompomJuice | I don't know how |
| 10:26.57 | pompomJuice | don't understand bbappend |
| 10:27.04 | pompomJuice | cannot find any documentation on it |
| 10:27.12 | pompomJuice | I am newby |
| 10:27.37 | mago_ | try this: http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#using-bbappend-files |
| 10:28.24 | pompomJuice | aah thanks |
| 10:29.04 | pompomJuice | but that code is probably in a class |
| 10:29.09 | pompomJuice | do you get a .classappend"? |
| 10:29.18 | pompomJuice | I mean |
| 10:29.23 | pompomJuice | .bbclassappend |
| 10:33.42 | mago_ | well, .bb files inherit stuff from classes. So I assume that you can apply a .bbappend to the recipe (which holds the functions you need). You should probably not make changes to the class itself, as it may be inherited by others aswell |
| 10:33.53 | pompomJuice | exactly! |
| 10:34.02 | pompomJuice | its a nightmare |
| 10:34.06 | pompomJuice | anyway |
| 10:34.08 | pompomJuice | I ahve to go now |
| 10:34.10 | pompomJuice | thanks for your help |
| 10:34.12 | pompomJuice | it has helped |
| 10:44.55 | *** join/#oe dbfi (~juha@85-131-124-52.bb.dnainternet.fi) |
| 10:54.40 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 10:56.28 | *** join/#oe rribalda (~ricardo@0x4dd4aed9.adsl.cybercity.dk) |
| 11:03.59 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 11:25.52 | CruX| | offtopic but sign this https://secure.avaaz.org/en/petition/computers_snowden_choose_before_paying/ |
| 11:32.35 | pompomJuice | anyone know how to suppress stripping in the kernel build process for certain files? |
| 11:32.59 | pompomJuice | ERROR: objcopy failed with exit code 256 (cmd was 'arm-angstrom-linux-gnueabi-objcopy' |
| 11:36.43 | pompomJuice | # |
| 11:36.44 | pompomJuice | <PROTECTED> |
| 11:36.44 | pompomJuice | <PROTECTED> |
| 11:36.44 | pompomJuice | <PROTECTED> |
| 11:36.44 | pompomJuice | <PROTECTED> |
| 11:36.44 | pompomJuice | <PROTECTED> |
| 11:36.45 | pompomJuice | <PROTECTED> |
| 11:36.45 | pompomJuice | <PROTECTED> |
| 11:36.46 | pompomJuice | <PROTECTED> |
| 11:36.52 | pompomJuice | that is inside the kernel.bbclass |
| 11:37.02 | pompomJuice | "We don not want..." |
| 11:37.05 | pompomJuice | I do want... |
| 11:43.15 | pompomJuice | wait |
| 11:43.26 | pompomJuice | I figured it out |
| 11:43.40 | pompomJuice | backup the files using a do_install_prepend |
| 11:43.50 | pompomJuice | restore the files doing a do_install_append |
| 11:44.15 | pompomJuice | delete the files again by adding a task between do_populate_sysroot & do_package |
| 11:44.17 | pompomJuice | poof |
| 11:54.13 | *** join/#oe joeythesaint (~jjm@128.224.252.2) |
| 11:56.16 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 12:13.25 | *** join/#oe tgall_foo (~tgall@70.35.96.184) |
| 12:13.25 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 12:15.13 | *** join/#oe uRandomMM (40c71302@gateway/web/freenode/ip.64.199.19.2) |
| 12:20.10 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 12:29.02 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 12:30.54 | *** join/#oe adelcast (~adelcast@130.164.62.193) |
| 12:33.40 | *** join/#oe halstead (~halstead@salt.incitedev.com) |
| 12:35.28 | *** join/#oe kscherer (~kscherer@128.224.252.2) |
| 12:41.43 | *** join/#oe ao2 (~ao2@host213-107-dynamic.57-82-r.retail.telecomitalia.it) |
| 12:50.00 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 12:56.10 | *** join/#oe tgall_foo (~tgall@70.35.96.184) |
| 12:56.10 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 13:22.53 | *** join/#oe darkschneider (~gab@93-32-59-224.ip32.fastwebnet.it) |
| 13:25.00 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 13:43.20 | *** join/#oe fabo (~fabo@a91-152-78-194.elisa-laajakaista.fi) |
| 13:43.21 | *** join/#oe fabo (~fabo@linaro/fabo) |
| 13:46.51 | *** join/#oe darknighte (~darknight@pdpc/supporter/professional/darknighte) |
| 14:04.38 | *** join/#oe crxz0193 (~crxz0193@123.201.133.117) |
| 14:07.32 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 14:18.51 | *** join/#oe _chase_ (~a0271661@nat/ti/x-auuxqecgbhmrfofj) |
| 14:35.08 | *** join/#oe fusman (~fahad@39.42.53.66) |
| 14:46.40 | *** join/#oe blilly (~blilly1@c-50-170-54-92.hsd1.wa.comcast.net) |
| 15:15.59 | *** join/#oe halstead (~halstead@drupal.org/user/301087/view) |
| 15:33.58 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 15:36.02 | *** join/#oe JaMa (~martin@ip-89-176-104-3.net.upcbroadband.cz) |
| 15:39.16 | mago_ | if a layer provides multiple kernels (both multiple versions, and multiple variants), how can I set which one to use when building my image? For example, Arago provides two versions of linux-ti-staging, but also a linux-ti33x-psp. The arago-console-image target currently builds linux-ti-staging (preferred version 3.10), how can I change this so that it instead uses linux-ti33x-psp to provide kernel? |
| 15:39.44 | fray | use PREFERRED_VERSION_<recipe> = "<version>" |
| 15:40.03 | fray | that goes in a .conf file of some kind.. BSP, local.conf, etc.. |
| 15:40.20 | *** join/#oe heeen (heeen@endboss.org) |
| 15:40.22 | mago_ | fray, yes, if I were to change the version of linux-ti-staging i guess that would suffice. But I want to not use package A, and instead use B in its place |
| 15:40.26 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 15:40.38 | mago_ | they both "provide" virtual/kernel |
| 15:41.03 | heeen | my oe fails to build pseudo-native: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc |
| 15:41.28 | heeen | so I'm kind of stuck, any idea how to solve this? is there an env variable to tell it to use 4.7 or 4.6 |
| 15:41.43 | heeen | what gcc versiopn does it like anyways |
| 15:41.44 | fray | that message comes from the system linker.. |
| 15:41.54 | fray | your system linker or gcc need to be fixed.. |
| 15:42.15 | heeen | linker seems to work okay outside of oe |
| 15:42.23 | fray | mago_ then you also need a PREFERRED_PROVIDER_virtual/kernel = "<recipe>" |
| 15:42.25 | heeen | unless I'm missing something here |
| 15:42.42 | fray | my guess is that you don't have the libgcc.a for the ABI you are trying to compile for.. |
| 15:42.44 | mago_ | fray, ah, I see. Thank you! |
| 15:42.55 | fray | pseudo needs to build for both 32-bit and 64-bit (in many cases).. |
| 15:43.03 | fray | so you need the libgcc.a that matches your compiler for both installed |
| 15:43.04 | heeen | target is arm |
| 15:43.16 | fray | this is pseudo-native, so the target is not involved |
| 15:43.21 | heeen | but pseudo native is for running on the build system itself, right? |
| 15:43.32 | fray | pseudo wraps system binaries to emulate a 'root-like' environment.. |
| 15:43.47 | fray | if it detects you have 32-bit binaries on your system (or could) it will try to build a 32-bit version fo itself.. |
| 15:43.59 | fray | I'm guessing this is what is failing because your libgcc.a is missing for the 32-bit side |
| 15:44.18 | heeen | why is 32bit involved at all |
| 15:44.45 | fray | because something on your system told it you either have 32-bit (host) binaries, or you have the ability to generate them.. |
| 15:44.58 | fray | pseudo can only wraper the binaries of the same bitsize as it was compiled for.. |
| 15:45.08 | fray | so you need a 32-bit pseudo for 32-bit binaries, and a 64-bit pseudo for 64-bit binaries.. |
| 15:45.22 | fray | the autodetection looks for specific headers to see if you have the 32-bit headers |
| 15:45.44 | heeen | /usr/bin/gcc: ELF 64-bit LSB executable, x86-64 |
| 15:46.03 | heeen | hmm |
| 15:46.13 | nerdboy | moin |
| 15:46.14 | fray | it's not wrapping gcc.. |
| 15:46.18 | fray | it's using gcc to build itself |
| 15:46.27 | heeen | right |
| 15:46.29 | fray | when you build something with gcc, it has to link the corresponding 'libgcc.a' |
| 15:46.47 | fray | the message from 'ld' says you don't have the corresponding libgcc for what you are compiling.. |
| 15:46.59 | fray | this usually indicates that you are trying to use a 64-bit version to link a 32-bit binary (or the reverse) |
| 15:47.04 | Daemon404 | awaits the day clang removes this mess |
| 15:47.09 | heeen | but doesn't it look like I have a 64bit gcc, still it doesn't like /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a |
| 15:47.12 | fray | clang won't do anything about this.. |
| 15:47.14 | fray | it's the same issue |
| 15:47.25 | Daemon404 | clang doesnt have a replacemrnt for libgcc fullstop |
| 15:47.36 | fray | it's building either a 32-bit pseudo and the linker is trying to link a 64-bit libgcc which will never work |
| 15:47.38 | fray | or the reverse |
| 15:47.46 | heeen | hrm |
| 15:47.58 | kergoth | just make sure you have the c library and libgcc for both 32 and 64 bit installed, and you'll be fine |
| 15:48.05 | fray | your host system either has 32-bit binaries that it detected, or it has support for building 32-bit binaries.. |
| 15:48.05 | Daemon404 | sorry, i didnt really mean solve *that* particular mess |
| 15:48.17 | fray | either one will trigger it to attempt to build a 32-bit pseudo.. |
| 15:48.49 | Daemon404 | i just meant that the canadian cross will in general be obsolete. |
| 15:48.51 | fray | primary key is /usr/include/gnu/stubs-32.h BTW |
| 15:49.17 | fray | you'll still have to create a compiler backend to target the 'target system' |
| 15:49.32 | fray | and you'll also still need to generate a 'clang' binary that runs in the environment you expect it to run in.. |
| 15:49.39 | fray | canadian-cross and cross compilers don't go away in clang |
| 15:50.07 | Daemon404 | they kind of do -- there's not one specific target |
| 15:50.13 | Daemon404 | it's all targets at once |
| 15:50.17 | fray | clang -> intermediate -> backend.. |
| 15:50.39 | mago_ | fray, do you know what might be wrong if Bitbake says "selecting linux-ti-staging to satisfy virtual/kernel due to PREFERRED_PROVIDERS", even though I have this in my local.conf: PREFERRED_PROVIDER_virtual/kernel = "linux-ti33x-psp" |
| 15:50.40 | fray | the backend is the cross compiler.. plus you need the clang to know the right set of inbuilt defines for the target you are well, targeting |
| 15:50.55 | fray | the clang binary itself will need to be compiled for the system you intend to run it on.. native, nativesdk or target.. |
| 15:50.58 | fray | so the candian cross is still there |
| 15:51.19 | fray | add an 's' to PREFERRED_PROVIDER ;) |
| 15:51.23 | fray | I dunno.. |
| 15:51.39 | fray | hiopefully just a simple typo.. but the preferred_provider is the key for selecting.. |
| 15:51.52 | fray | the other option you have is to include the blacklist class.. and blacklist the one you DO NOT want.. |
| 15:51.59 | Daemon404 | my point was it lacks the limitation of one target per build, since it can always build with all targets, so it's not *really* canadian cross in my mind |
| 15:51.59 | fray | USER_CLASSES += "blacklist" |
| 15:52.11 | fray | PNBLACKLIST[linux-ti-staging] = "Go away" |
| 15:52.23 | Daemon404 | i get what you mean, but it's much more simplified than what gcc does to me |
| 15:52.26 | Daemon404 | build-wise |
| 15:52.38 | fray | I find the blacklist useful in that it will trigger the system to tell you WHY it keeps bringing it in.. since the dep will fail |
| 15:53.04 | fray | Daemon404 -- it's just "different".. but in the end it's the same.. where clang is better is the overall pluggable architecture.. |
| 15:53.20 | fray | but building clang is still as complex as building any other set of compilers, libc, linkers, etc.. |
| 15:53.29 | Daemon404 | i specifically mean teh compiler |
| 15:53.35 | Daemon404 | not teh infastrcture like libc/c++ |
| 15:54.11 | Daemon404 | and it's certainly 'simpler' to me to have one toolchain targeting everything |
| 15:54.19 | Daemon404 | and softlinks with prefixes |
| 15:55.10 | fray | clang (via it's intermediates and other components) still has to know the system definitions (default #defines) and other header components for a specific 'target'. The intermediate format doesn't insulate that |
| 15:55.29 | Daemon404 | of course |
| 15:55.30 | fray | but the intermediate format allows more transformations of the data once the initial parsing/compiling has occured.. which is a big win.. |
| 15:55.32 | mago_ | fray, it seems like there are preferred providers such as this: PREFERRED_PROVIDER_virtual/kernel_MACHINE = "linux-ti-staging" .. I assume these are providers of a specific target, for a specific machine. Perhaps they override the more generic PREFERRED_PROVIDER_virtual/kernel = .. assignment? |
| 15:55.46 | fray | I really don't expect it to be any easier for the system builder.. it's going to be better though |
| 15:56.03 | fray | mago_ then you'll want ot override it.. |
| 15:56.11 | fray | or like I said, just blacklist it and kick it out of there.. |
| 15:56.13 | Daemon404 | it's been easier for me thus far to build and work with cross-dev chains w/ clang |
| 15:56.21 | Daemon404 | but that's a personal anecdote |
| 15:59.47 | *** join/#oe awozniak_ (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 16:01.20 | mago_ | fray, i see. the more specific PREFERRED_PROVIDER seem to override the more generic one: http://pastebin.com/yN1fDRY5 .. even if I make my local.conf PREFERRED_PROVIDER equally specific, it still uses linux-ti-staging. Perhaps a distro preferrence cannot be overridden, and must be blacklisted as you say? |
| 16:03.48 | fray | it has to do with load order and the mystical "override" mechanisms.. |
| 16:03.56 | fray | you can use bitbake -e and look at the order of the processing |
| 16:04.09 | fray | ahh yes.. whats in the pastebin |
| 16:04.23 | mago_ | partial output from bitbake -e :) |
| 16:04.49 | fray | it's the arago-prefs.in that is the 'issue'.. |
| 16:04.49 | *** join/#oe fusman (~fahad@39.42.53.66) |
| 16:04.59 | fray | you may just have to 'force' the value.. |
| 16:05.08 | fray | finds the example |
| 16:05.50 | fray | PREFERRED_PROVIDERS_virtual_kernel_forcevariable = "<your val>" |
| 16:05.51 | mago_ | still, there has to be a way to override distro settings ? or does that qualify as a new distro, i.e. i should fork the distro and just modify it directly |
| 16:05.59 | mago_ | oh, okay, ill try that |
| 16:06.03 | fray | you really should fork the distro for this.. |
| 16:06.13 | fray | what you can do is create your own with thef irst line being: |
| 16:06.16 | fray | require <original distro> |
| 16:06.16 | denix | fray: it's virtual/kernel, isn't it? |
| 16:06.31 | fray | PREFERRED_PROVIDER_virtual/kernel_<machine> = "your value" |
| 16:06.35 | fray | what kicer.. |
| 16:06.36 | fray | denix yes |
| 16:06.40 | fray | kicer -> nicer |
| 16:06.41 | denix | hence PREFERRED_VERSION_virtual/kernel_forcevariable |
| 16:07.07 | fray | forcevariable is the last thing evaluated.. so it'll work for testing.. but isn't really meant to be in use for a production environment.. |
| 16:07.13 | fray | the distro include/fork is the best way |
| 16:07.45 | mago_ | yeah, testing is fine. I'm just trying to get something that will boot on my board |
| 16:07.45 | denix | but distro has all the rights to set preferences |
| 16:07.57 | denix | so, please don't say it is the issue |
| 16:08.30 | mago_ | denix, yes, I agree. I'm not blaming anyone, i'm just looking for a quick fix to get things booting |
| 16:11.08 | mago_ | denix, this is part of my attempts to get Arago running on my custom AM3352 board. After I let U-boot run the uImage, nothing happens. I am unsure if it is because the serial output is broken, or if there is a more serious kernel issue when used on my board. I do have a buildroot tree based on the old TI kernel 3.2 which works, and I figured since arago uses 3.12, It might provide clues on what is wrong if I revert back to 3.2 in arago aswell |
| 16:12.10 | heeen | fray: /lib/x86_64-linux-gnu/libgcc_s.so.1: ELF 64-bit LSB shared object, x86-64 |
| 16:12.27 | heeen | hm nevermind |
| 16:12.52 | heeen | hm actually |
| 16:13.07 | heeen | could it be possible that it somehow picks up 32bit gcc from somewhere? |
| 16:13.16 | mago_ | fray, forcevariable worked! thanks |
| 16:13.19 | fray | heen you can tell the system to ignore teh automatic identification.. |
| 16:13.23 | fray | in your lcoal.conf |
| 16:13.28 | fray | NO32LIBS = '1' |
| 16:13.38 | heeen | how can I check what it thinks it detected |
| 16:13.42 | fray | but if you do have any 32-bit host binaries.. you'll get indeterminant results.. |
| 16:13.51 | fray | look at /usr/include/gnu/stubs-32.h |
| 16:13.51 | heeen | Build Configuration: |
| 16:13.53 | heeen | BB_VERSION = "1.18.0" |
| 16:13.55 | heeen | BUILD_SYS = "x86_64-linux" |
| 16:14.08 | fray | most likely that file exists which is triggering the behavior |
| 16:14.19 | heeen | yeah, it exists |
| 16:14.23 | heeen | where does it come from |
| 16:14.28 | *** part/#oe dbfi (~juha@85-131-124-52.bb.dnainternet.fi) |
| 16:14.35 | fray | that file existing normally indicate syou have at least partial 32-bit compiler support enabled.. |
| 16:14.45 | fray | thus pseudo tries to use it.. and it fails.. since it's not all installed.. |
| 16:14.51 | fray | thats up to your distribution.. |
| 16:15.00 | fray | either its a bug in the distro, or you installed some of the 32-bit support |
| 16:15.01 | heeen | I think I need ia32 libs for some stupid java VPN crap |
| 16:15.11 | fray | thats probably where it came from then.. |
| 16:15.29 | fray | either install the 32-bit devel libraries (for gcc and glibc) or just use the NO32LIBS = '1' |
| 16:16.13 | heeen | this hasn't been a problem before, though |
| 16:16.57 | fray | something in your config changes then |
| 16:17.00 | fray | 'er.. changed |
| 16:17.04 | heeen | how can I even clean pseudo-native |
| 16:17.34 | fray | bitbake -c cleansstate pseudo-native |
| 16:17.59 | heeen | it always tries to build it even when I want to cleanall it |
| 16:18.12 | fray | ahh.. thats cause pseudo is a base package.. |
| 16:18.28 | fray | set the NO32LIBS = '1' in your local.conf and it'll stop |
| 16:18.54 | heeen | I did and I opened a different can of worms |
| 16:19.11 | fray | you are going to need to dump your 'tmp' dir then.. (don't have to wipe anything else) |
| 16:19.20 | heeen | ERROR: Execution of event handler 'errorreport_handler' failed |
| 16:19.34 | fray | Don't know what that is.. |
| 16:20.42 | heeen | | Attempting to build 32-bit libpseudo.so for pseudo-native. |
| 16:20.47 | heeen | ffff |
| 16:21.57 | fray | I just checked and oe-core master still has the NO32LIBS = '1' setting.. |
| 16:22.32 | heeen | yeah, local.conf has it to uncomment and set to 0 if you need it |
| 16:22.34 | fray | http://pastebin.com/A7NczxS1 |
| 16:22.38 | heeen | doesn't stop it from trying 32bit |
| 16:22.46 | fray | are you using master? |
| 16:23.43 | *** join/#oe Crofton (~balister@64-186-172-226.static-ip.telepacific.net) |
| 16:25.56 | heeen | not sure |
| 16:26.08 | fray | how did you download OE? |
| 16:26.24 | heeen | company provided script |
| 16:27.12 | heeen | meta-oe is dylan |
| 16:27.30 | fray | meta-oe shouldn't be an issue with this.. but if it's dylan... then the core oe-core should be dylan as well.. |
| 16:27.45 | fray | if your bitbake/oe-core don't match that could be part of the problem |
| 16:28.00 | heeen | oe-core is dylan as well |
| 16:29.11 | *** join/#oe balister_ (~balister@64.186.172.226) |
| 16:34.27 | nerdboy | my stop-gap solution is apparently a 64-bit gentoo chroot shell running an x86 debian wheezy install |
| 16:35.25 | kergoth | chuckles |
| 16:38.15 | nerdboy | the default pseudo build doesn't like gentoo x86_64 multilib |
| 16:39.09 | fray | I've never tried it there.. what happens? |
| 16:39.33 | nerdboy | pseudo-native fails weirdly |
| 16:40.19 | fray | if a bug doesn't exist in the YP bugzilla.. please enter one.. I'd like to see what the failure is.. |
| 16:40.31 | nerdboy | i'd need to poke around and find a log somewhere |
| 16:40.42 | fray | the only 'regular' pseudo failure I'm used to is on systems where grsec (and sometimes selinux) are enabled.. they prevent pseudo from preloading and wrapping other binaries.. |
| 16:40.49 | fray | those security mechanisms just need to be disabled |
| 16:41.11 | nerdboy | this wasn't on anything hardened |
| 16:41.25 | nerdboy | just a normal amd64 profile |
| 16:41.46 | denix | no problem with gentoo x86_64 here |
| 16:43.18 | denix | had to play with NO32LIBS and set it to '0' I believe |
| 16:43.53 | fray | ya.. that's what I would expect assuming there are no 32-bit binaries on the system to be wrapped |
| 16:44.04 | fray | (assuming the autodetection doesn't work) |
| 16:44.42 | *** join/#oe challinan_ (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 16:44.49 | nerdboy | denix: not a multilib [rofile? |
| 16:46.07 | nerdboy | looks like multilib is now the default if you don't select one of the no-multilib profiles |
| 16:48.02 | denix | nerdboy: multilib with emul-linux-x86 |
| 16:48.16 | *** join/#oe kroon (~kroon@89-253-118-72.customers.ownit.se) |
| 16:53.18 | *** join/#oe dvhart (~dvhart@134.134.137.71) |
| 16:59.52 | nerdboy | i'll try again after i update |
| 17:00.28 | nerdboy | gotta remove some old ruby cruft... |
| 17:01.01 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 17:31.11 | *** join/#oe afournier (~admin@46.255.181.29) |
| 17:39.38 | *** join/#oe JoFo (~Jean-Fran@85.234.199.20) |
| 17:50.08 | *** join/#oe fusman (~fahad@39.42.53.66) |
| 17:52.45 | *** join/#oe CMoH (~cipi@78.96.92.66) |
| 17:52.45 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 17:59.22 | otavio | kroon: pong |
| 17:59.36 | *** join/#oe fusman (~fahad@39.42.53.66) |
| 18:00.13 | kroon | otavio, its ok, i was just wondering about the "make savedefconfig" thingie. nice trick! |
| 18:00.18 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 18:40.14 | *** join/#oe DJW|Home (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 18:45.30 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:46.06 | *** join/#oe kristoffer_ (~kristoffe@c-e882e253.171-2-64736c10.cust.bredbandsbolaget.se) |
| 18:47.16 | *** join/#oe kroon (~kroon@89-253-118-72.customers.ownit.se) |
| 18:50.26 | *** join/#oe JoFo (~Jean-Fran@ptra-178-50-66-184.mobistar.be) |
| 18:52.41 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 18:54.56 | *** join/#oe oneQubit_ (~oneQubit@c-98-231-154-140.hsd1.md.comcast.net) |
| 18:54.56 | *** join/#oe oneQubit (~oneQubit@c-98-231-154-140.hsd1.md.comcast.net) |
| 19:38.55 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 19:53.21 | *** join/#oe JoFo (~Jean-Fran@host-213-213-229-139.brutele.be) |
| 19:58.08 | *** join/#oe fusman1 (~fahad@39.42.16.197) |
| 20:21.09 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 20:22.54 | Crofton | How do I check if bitbake sees my bbappend? |
| 20:26.57 | denix | Crofton: bitbake-layers show-appends? |
| 20:30.50 | Crofton | how clever |
| 20:31.01 | Crofton | I may have just been an idiot though :) |
| 20:31.11 | *** join/#oe s3v3n62mm (~s3v3n62mm@p5DDC32CD.dip0.t-ipconnect.de) |
| 20:34.04 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 20:46.08 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 20:53.26 | *** join/#oe phdeswer (~phdeswer@a88-112-199-213.elisa-laajakaista.fi) |
| 20:59.21 | *** join/#oe CMoH (~cipi@78.96.92.66) |
| 20:59.36 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 21:26.51 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 21:41.16 | *** join/#oe adelcast1 (~adelcast@130.164.62.193) |
| 21:42.55 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 21:48.05 | *** join/#oe Igel_ (~igel@addicted.to.cjdns.meshte.ch) |
| 21:48.14 | *** join/#oe ccube (ccube@2a01:4f8:130:6ffc::82) |
| 21:49.26 | *** join/#oe LarrySteeze (LarrySteez@unaffiliated/larrysteeze) |
| 21:49.43 | *** join/#oe toobluesc (~nitro@2001:558:6045:7b:3d70:c3df:18a:884) |
| 21:50.56 | *** join/#oe ka6sox (ka6sox@nasadmin/ka6sox) |
| 21:51.26 | *** join/#oe scoutcamper (scoutcampe@nasadmin/webteam/scoutcamper) |
| 21:52.34 | *** join/#oe ericst (~ericst@2001:4b98:dc2:41:216:3eff:fe17:d3d0) |
| 21:53.38 | *** join/#oe nitink (nitink@nat/intel/x-sfgbkfvftawpvjsx) |
| 22:11.59 | *** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk) |
| 22:23.01 | *** join/#oe eric_st (~himself@2001:4b98:dc2:41:216:3eff:fe17:d3d0) |
| 22:39.18 | *** join/#oe ant_home (~ant__@host21-124-dynamic.54-82-r.retail.telecomitalia.it) |
| 22:55.59 | *** join/#oe JaMa (~martin@ip-89-176-104-3.net.upcbroadband.cz) |
| 23:47.38 | *** join/#oe GusBricker (~GusBricke@CPE-120-148-198-99.heum1.vic.bigpond.net.au) |
| 23:49.21 | *** join/#oe GusBrick_ (~GusBricke@CPE-120-148-198-99.heum1.vic.bigpond.net.au) |
| 23:50.03 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 23:54.14 | *** join/#oe Marex (~Marex@195.140.253.167) |