ibotlog2html for #crosstool-ng

<< Previous 2016-02-29 Next >>

# 06:44:38 xenoxaos quits : Ping timeout: 268 seconds
# 06:51:26 xenoxaos joins #crosstool-ng
# 07:04:48 JakeSays quits : Ping timeout: 244 seconds
# 07:05:55 JakeSays joins #crosstool-ng
# 07:23:04 blueness quits : Quit: blueness
# 07:24:07 blueness joins #crosstool-ng
# 07:48:31 diorcety joins #crosstool-ng
# 07:53:18 luc4 joins #crosstool-ng
# 07:58:49 luc4 Hello! I’m using a toolchain for an arm platform built using crosstool-ng. It seems some builds fail with many errors, like: fatal error: sys/cdefs.h: No such file or directory. I checked and cdefs.h is not missing, it is present both in the root filesystem of my board and in the toolchain. Still the compiler seems not to be able to find it. The toolchain I was previously using for the same platform was working properly and what I
# 07:58:49 luc4 that the header was in a different position. I see that the directory layout of the previous toolchain was identical to the one of the root filesystem while the layout of the new toolchain built using crosstool-ng is different. Is it possible this is the problem?
# 07:59:03 feepbot quits : Remote host closed the connection
# 08:01:23 feepbot joins #crosstool-ng
# 08:30:28 diorcety quits : Quit: Leaving.
# 09:16:26 diorcety joins #crosstool-ng
# 09:19:36 blueness quits : Quit: blueness
# 09:26:05 blueness joins #crosstool-ng
# 11:10:21 mingwandroid joins #crosstool-ng
# 11:28:00 mingwandroid quits : Ping timeout: 246 seconds
# 11:59:29 luc4 quits : Quit: luc4
# 14:46:48 enunes joins #crosstool-ng
# 16:46:22 philenotfound quits : *.net *.split
# 16:48:21 philenotfound joins #crosstool-ng
# 17:00:51 mingwandroid joins #crosstool-ng
# 17:01:06 mingwandroid quits : Read error: Connection reset by peer
# 17:13:00 systmkor joins #crosstool-ng
# 17:23:15 diorcety quits : Ping timeout: 248 seconds
# 17:59:41 y_morin joins #crosstool-ng
# 18:22:32 luc4 joins #crosstool-ng
# 18:24:26 luc4 Hello! As a general rule, is it necessary that the directory layout is identical between the toolchain and the root filesystem?
# 19:16:34 blueness quits : Quit: blueness
# 19:51:32 blueness joins #crosstool-ng
# 19:55:10 diorcety joins #crosstool-ng
# 21:18:05 diorcety quits : Quit: Leaving.
# 21:28:56 luc4 quits : Ping timeout: 268 seconds
# 21:49:57 aquarat quits : Ping timeout: 246 seconds
# 22:12:42 aquarat joins #crosstool-ng
# 22:14:04 luc4 joins #crosstool-ng
# 22:32:14 bhundven yes... I know... I broke master with the musl-libc update :(
# 22:32:45 bhundven I didn't realize they moved to out of tree build now =>1.1.13
# 22:33:02 bhundven I got a fix on the way
# 22:37:50 bhundven luc4: it depends
# 22:39:16 bhundven luc4: if your toolchain sysroot gets copied into your base system (like it would with buildroot) then it should be as close as possible.
# 22:39:42 bhundven I know there is a path issue with raspberry pi binaries
# 22:54:46 luc4 bhundven: rpi yes, I’m talking about that
# 22:55:10 bhundven luc4: yes, their lib directory is in a weird spot
# 22:55:26 luc4 bhundven: is it something that I can change from config?
# 22:55:29 bhundven (well, usr/lib)
# 22:55:34 bhundven luc4: no
# 22:55:46 bhundven luc4: it's kinda hard coded
# 22:56:21 bhundven luc4: it would be nice if it was configurable.
# 22:56:49 luc4 bhundven: for instance /usr/include/arm-linux-gnueabihf/sys/cdefs.h in the sysroot is in arm-linux-gnueabihf/sysroot/usr/include/sys/cdefs.h.
# 22:57:15 y_morin quits : Quit: Nighty Night!
# 22:57:46 luc4 bhundven: I’m not sure I understand why the compiler is not able to find it. Can you explain?
# 22:57:55 bhundven yes
# 22:58:12 bhundven /usr/include/arm-linux-gnueabihf is a non-standard (non-lsb) install location
# 22:58:35 bhundven /usr/include is a standard (lsb) install location
# 22:59:25 bhundven the compiler on the RPI is specifically looking in the non-standard location
# 22:59:55 luc4 bhundven: ok, but I see that header is also in the toolchain. That is not clear to me. The compiler does not know where to find a header its own toolchain has.
# 23:00:31 bhundven look at the two paths again
# 23:00:38 bhundven /usr/include/arm-linux-gnueabihf/sys/cdefs.h
# 23:00:43 bhundven /usr/include/sys/cdefs.h
# 23:01:06 luc4 yes, I see they are different
# 23:01:21 bhundven I can't explain the rpi compiler
# 23:01:29 bhundven I can explain the crosstool-ng compiler for rpi
# 23:01:54 bhundven why they don't look in the standard location? I'm not sure why
# 23:03:42 luc4 bhundven: wait, I’m not probably clear in my question: crosstool-ng toolchain has cdefs.h in the place it considers appropriate. Why is the crosstool-ng compiler unable to find its own header which is in the appropriate place? I understand it can’t find the one in the sysroot because the dir layout is wrong, but that header is in the toolchain itself.
# 23:04:57 luc4 bhundven: which leads to another more general question: if there are two cdefs.h, one in the toolchain and one in the sysroot… which one has the precedence?
# 23:07:36 bhundven luc4: I'm getting confused
# 23:07:44 bhundven luc4: do you have an example you can show me?
# 23:08:15 bhundven luc4: the build environment can change include orders, set non-standard include locations, etc...
# 23:10:39 luc4 bhundven: this is a real example: cdefs.h is not found during a build. I checked in the crosstool-ng toolchain and cdefs.h is in ./arm-linux-gnueabihf/sysroot/usr/include/sys/cdefs.h. In the sysroot instead it is in /usr/include/arm-linux-gnueabihf/sys/cdefs.h. In the old toolchain was in fact in ./arm-linux-gnueabihf/libc/usr/include/arm-linux-gnueabihf/sys/cdefs.h. So that is why I thought the layout was the probl
# 23:10:39 luc4 not clear to me is: why isn’t the crosstool-ng compiler able to find cdefs.h when he has it in the toolchain in arm-linux-gnueabihf/sysroot/usr/include/sys/cdefs.h?
# 23:10:47 bhundven no
# 23:10:52 bhundven start at the higher level
# 23:10:59 bhundven you have raspian installed
# 23:11:08 bhundven you're trying to cross-compile something to it
# 23:11:10 luc4 bhundven: yes
# 23:11:18 bhundven what is it you're compiling
# 23:11:25 luc4 bhundven: Qt libraries
# 23:11:36 bhundven ok, and where is the source coming from for that?
# 23:11:44 luc4 bhundven: Qt git
# 23:11:45 bhundven from Qt's site?
# 23:11:46 bhundven ok
# 23:12:02 bhundven and you're just using crosstool-ng and not the raspian gcc
# 23:12:04 luc4 bhundven: everything builds properly with the old rpi toolchain
# 23:12:15 luc4 bhundven: which was probably not crosstool-ng
# 23:12:19 bhundven right
# 23:12:34 luc4 bhundven: now I would like to switch to the new crosstool-ng toolchain
# 23:12:42 luc4 bhundven: so I switch it
# 23:12:59 luc4 bhundven: for convenience I leave my scripts identical
# 23:13:11 luc4 bhundven: and replace the toolchain root
# 23:13:36 luc4 bhundven: configure fails immediately
# 23:13:47 luc4 bhundven: one of the errors is cdefs.h not found
# 23:13:52 bhundven ok
# 23:14:19 luc4 bhundven: cdefs.h is in a bad place in the sysroot
# 23:14:35 luc4 bhundven: but it is in a good place in the toolchain
# 23:15:05 luc4 bhundven: by sysroot I mean “mounted root filesystem of the pi on my host via sshfs"
# 23:15:38 luc4 bhundven: I perfectly understand the compiler being unable to find cdefs.h in the sysroot (wrong location)
# 23:15:40 bhundven ok, that was where I was confused
# 23:15:53 bhundven your definition of sysroot
# 23:16:16 luc4 bhundven: yes, sysroot is the root of my target filesystem
# 23:16:24 luc4 bhundven: is the name wrong?
# 23:16:36 bhundven as opposed to the toolchain's sysroot
# 23:16:51 luc4 bhundven: ah ok, sysroot of the target
# 23:16:51 bhundven (which is what I was thinking)
# 23:17:05 bhundven confusion==0
# 23:17:07 bhundven :)
# 23:17:09 luc4 :-)
# 23:17:23 luc4 not sure why the compiler is unable to find a header which is part of its own toolchain
# 23:17:35 bhundven so now the issue is getting crosstool-ng to look in /usr/include/arm-linux-gnueabihf/
# 23:17:43 bhundven right?
# 23:17:57 bhundven because that is the -sysroot
# 23:18:08 luc4 bhundven: either that or… arm-linux-gnueabihf/sysroot/usr/include/sys/cdefs.h
# 23:18:23 luc4 bhundven: withing the toolchain I mean
# 23:18:29 luc4 bhundven: there are two cdefs.h here
# 23:18:44 luc4 one in the target filesystem and one in the toolchain
# 23:18:46 bhundven right, I understand that, but now it's up to how you are configuring qt
# 23:19:06 luc4 bhundven: ok, —sysroot refers to target filesystem
# 23:19:20 luc4 bhundven: so the compiler is goind to ignore its own sysroot completely?
# 23:19:29 bhundven right
# 23:19:33 luc4 bhundven: ok, clear
# 23:19:41 bhundven now, another thing
# 23:19:43 luc4 bhundven: I’m screwed :-D
# 23:19:50 bhundven no, not yet
# 23:19:51 bhundven :)
# 23:20:29 bhundven type your ct-ng gcc with -dumpmachine
# 23:20:40 bhundven -gcc -dumpmachine
# 23:21:09 bhundven I think we did a hack to get rid of the vendor for this kind of issue.
# 23:21:27 luc4 bhundven: just a sec, my machine is booting
# 23:21:41 bhundven no, I mean your crosstool-ng toolchain
# 23:21:50 bhundven you shouldn't need to boot the rpi
# 23:22:10 luc4 bhundven: I mean my virtual machine
# 23:22:14 bhundven ah, ok,
# 23:22:35 luc4 bhundven: arm-linux-gnueabihf
# 23:22:43 luc4 this is the output
# 23:22:54 bhundven that is the one you built with crosstool-ng?
# 23:23:23 luc4 bhundven: not me, provided by the manufacturer, but he told me he built using crosstool
# 23:23:34 luc4 bhundven: and also the config is provided
# 23:23:46 bhundven well
# 23:23:56 bhundven does he have the source posted somewhere?
# 23:24:07 luc4 bhundven: source of what?
# 23:24:09 bhundven I'm guessing he made some changes
# 23:24:13 bhundven crosstool-ng
# 23:24:22 luc4 bhundven: of the conifg file? yes
# 23:24:26 bhundven no
# 23:24:33 bhundven of the tree he used to build crosstool-ng
# 23:25:04 luc4 bhundven: yes, he told me… just a sec
# 23:25:09 bhundven :)
# 23:25:22 luc4 bhundven: commit 8460611d5f28c9b4d8e1533238f048119a1f4a63
# 23:25:29 luc4 Author: Bryan Hundven
# 23:25:38 luc4 I suppose it’s you :-D
# 23:25:58 luc4 lucky me… I found the right huy :-D
# 23:26:03 bhundven well
# 23:26:05 luc4 *guy
# 23:26:26 bhundven sure, ok, post the config somewhere
# 23:26:37 luc4 https://github.com/raspberrypi/tools/blob/master/configs/arm-rpi-4.9.3-linux-gnueabihf.config
# 23:27:30 bhundven huh
# 23:27:40 bhundven I didn't know rpi was using crosstool-ng
# 23:28:23 luc4 bhundven: I asked for a new toolchain because the old one was too old for jessie
# 23:28:59 luc4 bhundven: I fixed the old one but… better to go on to something better if possible
# 23:29:06 bhundven right, it's 5.3 now
# 23:29:15 luc4 gcc you mean?
# 23:29:19 bhundven yea
# 23:29:21 bhundven in jessie
# 23:29:27 bhundven er, isn't it
# 23:29:29 luc4 jessie is built with 4.9.3 I suppose
# 23:29:34 bhundven oh
# 23:29:42 luc4 4.8 was mostly working
# 23:29:53 luc4 but not when linking to the damn icu
# 23:30:34 bhundven 1.15.2
# 23:30:38 bhundven that was an old build
# 23:30:39 luc4 and of course I need it :-D but rebuilding fixed everything. still would be very interesting to learn ct-ng and move to something new
# 23:31:08 bhundven https://github.com/raspberrypi/tools/blob/master/configs/ct-nt-version
# 23:31:17 luc4 also I have to say I had similar issues with ubuntu mate on pi
# 23:33:05 luc4 do you think it is possible to somehow build with different paths? also… I’m wondering how do I know if there are other weird paths to fix…
# 23:34:28 bhundven https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf
# 23:35:10 bhundven I'm not exactly sure what is going on there.
# 23:35:37 luc4 that is what i’m using
# 23:35:50 bhundven ok
# 23:36:05 bhundven I'm trying to fix the master build right now, because I broke it :P
# 23:36:20 bhundven I have no clue without trying to build myself what your issue is.
# 23:36:31 bhundven but I need to fix the build right now
# 23:36:51 bhundven I've seen your issue on google
# 23:37:03 bhundven (other people having the same issue)
# 23:37:11 bhundven so I'm sure someone has an answer
# 23:38:50 luc4 bhundven: if you are busy right now no problem, I can come back tomorrow, I’m sure the pi community can gain from a “fix”
# 23:39:27 bhundven Yup, I've heard about issues about this, which is why I mentioned the path issue so early in the conversation
# 23:39:39 bhundven but on the other hand
# 23:40:32 bhundven crosstool-ng is not meant to be compatible with compilers provided by distributions, like debian or fedora, as their toolchains are sometimes different
# 23:40:39 bhundven from eachother
# 23:41:01 luc4 bhundven: I perfectly understand
# 23:41:38 bhundven I've had this debate with others as well that wanted a "native toolchain on an existing distribution"
# 23:42:04 luc4 bhundven: btw… https://github.com/raspberrypi/tools/tree/master/configs
# 23:42:09 bhundven yes
# 23:42:12 bhundven I saw that
# 23:42:23 luc4 bhundven: it seems a bit like even the older toolchain were built with ct-ng
# 23:42:34 bhundven yes
# 23:42:39 bhundven I saw that :)
# 23:42:49 luc4 then I ask myself why this problem arises now
# 23:43:08 bhundven I am not sure
# 23:43:27 bhundven I will look into it when I can.
# 23:43:48 bhundven but let me know if you figure it out before me :)
# 23:47:15 bhundven https://github.com/raspberrypi/tools/issues/50
# 23:48:00 luc4 bhundven: yes, carlonluca its me :-)
# 23:49:04 bhundven ok
# 23:50:08 luc4 bhundven: I’d be glad to help but I know very little about ct-ng. However I’m about to build pretty large projects so if you need some extensive test... :-)
# 23:50:19 luc4 bhundven: Qt, webkit, chromium etc...
# 23:50:35 luc4 and my env is all setup properly with the old toolchain
# 23:56:11 luc4 bhundven: do you own an rpi?
# 23:57:30 bhundven v1 b+
# 23:57:45 bhundven wants an rpi v2
# 23:57:58 bhundven (if anyone feels like donating :) )
# 23:58:10 luc4 bhundven: this is collaboration :-D luc4 wants rpi v3 :-D
# 23:58:53 luc4 bhundven: unfortunately I’m a poor engineer working just for open projects myself :-D
# 23:59:09 bhundven I mean model 2

Generated by ibotlog2html by Yann E. MORIN