| # 02:45:44 |
perr |
joins #crosstool-ng |
| # 02:45:44 |
perr |
quits : Changing host |
| # 02:45:44 |
perr |
joins #crosstool-ng |
| # 03:39:56 |
perr |
quits : Ping timeout: 250 seconds |
| # 04:53:21 |
blueness_ |
quits : Quit: blueness_ |
| # 04:53:45 |
blueness_ |
joins #crosstool-ng |
| # 06:17:37 |
blueness_ |
quits : Quit: blueness_ |
| # 06:18:25 |
blueness_ |
joins #crosstool-ng |
| # 06:54:39 |
diorcety |
joins #crosstool-ng |
| # 06:56:40 |
diorcety |
quits : Read error: Connection reset by peer |
| # 07:18:55 |
pamaury |
joins #crosstool-ng |
| # 07:39:13 |
perr |
joins #crosstool-ng |
| # 07:45:23 |
pamaury |
quits : Ping timeout: 265 seconds |
| # 08:52:14 |
perr |
quits : Ping timeout: 256 seconds |
| # 09:40:53 |
pamaury_ |
joins #crosstool-ng |
| # 09:52:59 |
pamaury_ |
quits : Ping timeout: 244 seconds |
| # 10:04:29 |
blueness_ |
quits : Quit: blueness_ |
| # 10:09:12 |
blueness_ |
joins #crosstool-ng |
| # 10:11:14 |
blueness_ |
quits : Client Quit |
| # 10:38:51 |
enunes |
joins #crosstool-ng |
| # 11:32:18 |
yann-kaelig |
joins #crosstool-ng |
| # 12:38:51 |
yann-kaelig |
Hi |
| # 12:39:35 |
yann-kaelig |
I have built a crosstool-ng crosscompiler for my cubieboard2. I start a test with u-boot but there is a bug |
| # 12:39:38 |
yann-kaelig |
{standard input}:336: Error: push/pop do not support {reglist}^ -- `pop {r0,r1,r2,r3,r4,r9,ip,pc}^' |
| # 12:40:07 |
yann-kaelig |
I think there is a patch for gcc, but I have no idea if the patch has been applied for ct-ng |
| # 12:42:02 |
yann-kaelig |
Here is the log of the u-boot build http://dpaste.com/23M0A7F |
| # 12:45:02 |
enunes |
yann-kaelig: which gcc version do you use, if you know which patches are needed can you check if your version already contains it? otherwise, all ct-ng applies patches are in patches/gcc/ in the ct-ng source |
| # 12:46:03 |
yann-kaelig |
enunes, Hi crosscompiler -v http://dpaste.com/2QSD7RZ |
| # 12:52:28 |
enunes |
yann-kaelig: I'd suggest trying to build it with a toolchain built with the generic arm-unknown-linux-gnueabi sample (it should also work with the cubieboard2), if this is a gcc bug maybe it's related to some optimization you have enabled |
| # 12:55:34 |
yann-kaelig |
enunes, ok. yes, that could be also my optimisation, this is first time on crosstool-ng, I'm goign to find what going wrong. |
| # 13:41:38 |
pamaury_ |
joins #crosstool-ng |
| # 13:46:26 |
pamaury_ |
quits : Ping timeout: 265 seconds |
| # 15:04:17 |
Guma |
joins #crosstool-ng |
| # 15:24:06 |
Guma |
I have general question about building tools. When my target is specific linux kernel does it make sense to build using crosstool-ng and select the latest kernel available? Can someone with experience shad some light on this for me? |
| # 15:24:46 |
Guma |
I small project and I am starting in linux/embedded development |
| # 15:25:56 |
enunes |
Guma: that's kernel headers. kernel headers have to be older than or equal to, the kernel you will be running, otherwise you will get a 'kernel too old' message on boot. they are also forward-compatible, so you can use some which are a bit older than your run kernel. |
| # 15:26:00 |
pamaury_ |
joins #crosstool-ng |
| # 15:27:03 |
enunes |
Guma: however, some applications require some recent kernel features, and for that you need recent kernel headers. So, use some kernel headers which are older to than the oldest kernel you plan to run, but not too old that soem applications might fail to build due to missing features |
| # 15:27:18 |
Guma |
enunes Kernel too old? I am not doing baretetal but just apps to specific linux target. Where does boot in my case comes to play |
| # 15:29:50 |
enunes |
Guma: if you have the glibc from your toolchain built with newer kernel headers on your target, it will complain on boot. and it makes sense, because glibc may be relying on features which might not be available in the running kernel |
| # 15:31:12 |
Guma |
enunes I did clone master and that is what I am using to build tools. The strange thing is that if I build gdb from same tarsal on my Mac it build fine (But this is targeted for Mac OS). This is using same compiler that crosstools-ng is using. When I build it myself it builds fine. In crosstool-ng I get error about use of "undeclared identifier 'LONG_MI". From your experience do you know where to start looking? Are the some |
| # 15:31:12 |
Guma |
extra flags that needs to be passed to crosstool-ng config? |
| # 15:32:24 |
enunes |
Guma: sorry, I don't know about Mac OS... |
| # 15:32:45 |
Guma |
enunes But at this stage I am interested on building just apps NOT building kernel. So still not clear about how booting makes difference in my case. I see your point if I would cross build kernel ... |
| # 15:33:36 |
Guma |
enunes I have some changes related to Mac in my local git. When I get all resolved I will do pull request when I will also test if first on Linux. |
| # 15:34:01 |
enunes |
Guma: you don't have to build the kernel. If you build the kernel with some other toolchain, and try to run userspace with glibc newer than that kernel, you would still run into the problem I described |
| # 15:34:39 |
Guma |
enunes Thank you I am clear now |
| # 15:34:41 |
Guma |
Is anyone else here who is interested or doing work on Mac? |
| # 15:36:57 |
Guma |
enunes So the best and safest practice for now for me is to select kernel/gcc/libc/gdb as the same as my target? Or I should be good only with gcc/gdb using latest? |
| # 15:39:49 |
enunes |
Guma: if you intend to build applications to run in a different userspace (not deploying the glibc built from your new toolchain), you should make sure to use the same versions you will have on the target. I don't do this either so I'd try to figure out the verisons present in the target |
| # 15:40:10 |
enunes |
Guma: you can find out the kernel headers used in /usr/include/linux/version.h |
| # 15:40:52 |
Guma |
enunes Thank you :) |
| # 15:41:57 |
pamaury_ |
quits : Ping timeout: 265 seconds |
| # 15:44:12 |
Guma |
enunes one more thing :) can I use my local gdb build for intel to connect to remote gdb (ARM) to debugging. Or Do I have to build gdb to run locally on intel but connect to ARM? How does this work? |
| # 15:44:56 |
Guma |
I am googling about this but this specific question I can't find answer. Everyone talk about how to debug. |
| # 15:45:38 |
enunes |
Guma: you probably can't use your x86 gdb to talk to an arm gdbserver. what I usually do is to build a pair cross-gdb/gdbserver (ct-ng does that) and just use it. |
| # 15:46:42 |
Guma |
Ok I do have enabled this. But since I am having problem with this maybe I was trying to solve something that is not needed in my case. But looks like I will have to fix this first. |
| # 15:49:44 |
yann-kaelig |
there is something I don't understand in menuconfig and local patch. How crosstool-ng is able to use my patch for gcc ? |
| # 15:56:18 |
yann-kaelig |
I have to create the same tree as patches $HOME/$localpatch/gcc/6.1.0/ put the patch in this folder and set my local path for patch in menuconfig in this way $HOME/$localpatch ? |
| # 18:29:47 |
alan_o |
quits : Ping timeout: 256 seconds |
| # 18:34:26 |
yann-kaelig |
well, I have build a new crosscompiler with an older gcc-4.9.x from menuconfig, no others change. There is no bug u-boot compilation success |
| # 18:34:55 |
yann-kaelig |
This is the thread about gcc-6.x with patch https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830 |
| # 18:35:16 |
yann-kaelig |
but I have no idea how to use this patch on ct-ng |
| # 18:35:36 |
yann-kaelig |
for a test |
| # 18:37:10 |
enunes |
yann-kaelig: it seems that the patch fixes a generic problem, you can put it into patches/gcc/ inside the crosstool-ng sources and test it, if it works you can send a pull request on github |
| # 18:43:01 |
alan_o |
joins #crosstool-ng |
| # 18:43:13 |
yann-kaelig |
enunes, ok this is what I done the first time. But no output on the screen if my patch is applied. I tried to find somethign in the log, but it's really big. |
| # 18:45:37 |
enunes |
quits : Ping timeout: 265 seconds |
| # 18:58:36 |
pamaury |
joins #crosstool-ng |
| # 19:00:02 |
enunes |
joins #crosstool-ng |
| # 20:46:50 |
blueness_ |
joins #crosstool-ng |
| # 20:55:26 |
blueness_ |
quits : Quit: blueness_ |
| # 21:00:11 |
Guma |
enunes: Is there a switch to only build last failed project? So I am having trouble with debug and want to just restart this section |
| # 21:05:58 |
enunes |
Guma: you can enable one of the options in "Paths and misc options" -> "Debug crosstool-NG", I remember using "Interactive shell on failed commands" a few times, never tried "Save intermediate steps" but according to the help text, it may be what you want |
| # 21:08:03 |
Guma |
Ok Will try this |
| # 21:12:44 |
blueness_ |
joins #crosstool-ng |
| # 21:41:52 |
blueness_ |
quits : Quit: blueness_ |
| # 22:02:57 |
Guma |
I am reading ng documentation and I stumbled upon ct-ng build-all. What is the different between ct-ng build? Is build-all is used only in debugging and will "build" all by passing Y for each step? |
| # 22:18:07 |
blueness_ |
joins #crosstool-ng |
| # 22:48:44 |
pamaury |
quits : Ping timeout: 265 seconds |
| # 23:22:21 |
blueness_ |
quits : Quit: blueness_ |
| # 23:26:32 |
blueness_ |
joins #crosstool-ng |