# 03:10:19 |
falstaff |
joins #crosstool-ng |
# 03:12:38 |
falstaff_ |
quits : Ping timeout: 240 seconds |
# 05:54:29 |
ldm |
quits : Read error: Connection reset by peer |
# 05:55:03 |
ldm |
joins #crosstool-ng |
# 09:57:38 |
sh4rm4 |
quits : Remote host closed the connection |
# 10:09:24 |
y_morin |
joins #crosstool-ng |
# 10:14:43 |
sh4rm4 |
joins #crosstool-ng |
# 10:22:32 |
hrubi |
quits : Ping timeout: 260 seconds |
# 11:00:52 |
smartin_ |
joins #crosstool-ng |
# 11:21:43 |
saedelaere |
joins #crosstool-ng |
# 11:24:40 |
saedelaere |
I tried to create an arm toolchain with crosstools-ng on my archlinux x86_64 |
# 11:24:48 |
saedelaere |
I used this tutorial http://prototypem.com/article/cross-compiling-for-the-raspberry-pi |
# 11:24:57 |
saedelaere |
but I get a build error |
# 11:26:19 |
saedelaere |
these are the last lines of the build pocess |
# 11:26:20 |
saedelaere |
http://ideone.com/UWal0B |
# 11:28:07 |
saedelaere |
I am uploading the complete build.log |
# 11:35:44 |
saedelaere |
you can download the file here: https://crappbytes.org/owncloud/public.php?service=files&t=186c2c0a4773d4ca6364ecf2e44d1394 |
# 12:03:02 |
y_morin |
saedelaere: Hello! Update to crosstool-NG 1.19.0, there is a sample for the RPi. |
# 12:03:10 |
y_morin |
saedelaere: you can get to build it with: |
# 12:03:25 |
y_morin |
saedelaere: ./ct-ng armv6-rpi-linux-gnueabi |
# 12:04:17 |
y_morin |
saedelaere: As for your 'critical programs are missing or too old: make' issue: what is the output of: 'make --version' ? |
# 12:04:50 |
y_morin |
It should be at least mae 3.81 |
# 12:05:10 |
y_morin |
got to go for Lunch. Back in ~1h... |
# 12:07:25 |
saedelaere |
y_morin: |
# 12:07:27 |
saedelaere |
$ make --version |
# 12:07:27 |
saedelaere |
GNU Make 4.0 |
# 12:07:43 |
saedelaere |
maybe thats to new |
# 12:07:46 |
saedelaere |
:) |
# 12:32:49 |
falstaff |
quits : Read error: Operation timed out |
# 12:39:14 |
RzR |
joins #crosstool-ng |
# 12:40:23 |
falstaff |
joins #crosstool-ng |
# 12:51:02 |
saedelaere |
y_morin: also failed |
# 12:51:11 |
saedelaere |
I found this in the build log: [CFG ] checking version of make... 4.0, bad |
# 12:51:30 |
saedelaere |
so it seems it does not recognize the new make command |
# 13:14:08 |
saedelaere |
I have build make 3.82 on my machine and installed it as make-3.82 in /usr/bin |
# 13:14:19 |
saedelaere |
how to tell crosstool-ng to use this make? |
# 13:23:26 |
saedelaere |
allow glibc to be build with make 4.0 |
# 13:23:27 |
saedelaere |
http://www.linuxfromscratch.org/lfs/view/SVN-20131015/chapter06/glibc.html |
# 13:23:35 |
smartin_ |
saedelaere: you can specify the make binary when configuring ct-ng |
# 13:24:14 |
smartin_ |
just run './configure --help' to get the option to set |
# 13:25:08 |
saedelaere |
smartin_: does crosstool-ng allow to apply patches? |
# 13:25:19 |
saedelaere |
in the link I posted they say one should use: sed -r -i 's/(3..89..)/\1 | 4.*/' configure |
# 13:25:42 |
saedelaere |
thios would allow me to build glibc with make 4 |
# 13:26:26 |
smartin_ |
saedelaere: i think so, but cannot confirm. |
# 13:26:29 |
smartin_ |
gtg |
# 13:35:34 |
y_morin |
saedelaere: yes, make-4.0 is too new, and breaks some components. |
# 13:35:45 |
y_morin |
saedelaere: you can tell ct-ng to build its own version of make: |
# 13:36:29 |
y_morin |
saedelaere: First, enable EXPERIOMENTAL in 'Paths and misc options' |
# 13:37:06 |
y_morin |
saedelaere: Then, go in 'Companion tools' (at top-level) and enable 'Build some companion tools' and then 'make' |
# 13:37:21 |
y_morin |
saedelaere: Then exit (and save). |
# 13:37:36 |
y_morin |
s/EXPERIOMENTAL/EXPERIMENTAL/ |
# 13:37:49 |
y_morin |
saedelaere: What is your distro, btw? |
# 13:38:49 |
saedelaere |
archlinux --> bleeding edge :) |
# 13:38:58 |
y_morin |
curses this newer 'make' that break established behaviour, and thus break existing programs |
# 13:39:10 |
y_morin |
saedelaere: Ah, arch is too bleeding edge, indeed. |
# 13:39:45 |
y_morin |
saedelaere: the best course of actions for you is to have ct-ng build its own version of make (see above). |
# 13:40:48 |
saedelaere |
y_morin: so far I am super happy with archlinux. doing a lot of development on the machine and it is very stable. sometimes it is just a bit ahead of time ;) |
# 13:40:50 |
y_morin |
saedelaere: even make-3.82 broke some Makefiles, especially the glibc and Linux ones., |
# 13:44:27 |
saedelaere |
y_morin: if I wanted to apply the the sed command I posted to glibc configure script, how can I prevent ct-ng to download glibc again and overwrite my changes? dosn't it use the predownloaded sources in .build/src/ ? |
# 13:44:56 |
saedelaere |
oh wait |
# 13:45:05 |
saedelaere |
in fact it didn't overwrite my changes |
# 13:45:40 |
y_morin |
saedelaere: No, you should not have to do that: read what I said about having ct-ng build its own 'make' version. |
# 13:46:07 |
y_morin |
saedelaere: make-4 broke a lot of things, and just running the sed on glibc's ./configure is not guaranteed to work. |
# 13:46:23 |
saedelaere |
Installing C library headers & start files: done in 12.08s (at 05:53) -- this failed all the time before :) so the sed "patch" was applied successfull |
# 13:46:32 |
saedelaere |
y_morin: ok understood |
# 13:46:53 |
saedelaere |
I leave it running and will see whats happening |
# 13:47:19 |
saedelaere |
if it fails again on a different spot I will use the method you described. thank you very much!! |
# 13:48:49 |
y_morin |
saedelaere: glibc's Makefiles were written for make-3.81. make-3.82, and then make-4.0, broke established behaviour of make, so just bumping the supported make version in glibc's ./configure will just hide the issue at best. At worst, glibc will build but incorrectly; at best, the build will fail later on. |
# 13:49:10 |
y_morin |
saedelaere: as you wish, but what I wrote above is known to work. |
# 13:50:24 |
saedelaere |
y_morin: I believe you :) |
# 13:59:54 |
saedelaere |
y_morin: build completed in 16:45.76. my first self build cross compiler toolchain. I'll create a simple c++ programm and see if it runs on my raspberry pi. do you know if I need to statically link my executable against the compiled glibc? I suppose so. I think raspbian ships glibc 1.15 |
# 14:05:32 |
y_morin |
saedelaere: crosstool-NG is not designed to be used to target an existing system. It is meant for completely from-scratch systems. |
# 14:05:48 |
y_morin |
saedelaere: Targetting an existing system may or may not work. |
# 14:06:24 |
y_morin |
saedelaere: if you want to target an existign system, then use the tools for that system. In your case, use the toolchains from raspbian. |
# 14:06:53 |
y_morin |
saedelaere: Or build the system completely from scartch (eg. using Buildroot) |
# 14:08:27 |
saedelaere |
y_morin: hmm did not know that. cross compiling really is no simple task I see |
# 14:09:16 |
saedelaere |
but compiling on the pi is simply to slow and I have no IDE there as I don't start X |
# 14:10:45 |
saedelaere |
the raspberry pi foundation offers it's own crosscompiler toolchain. but is based on gcc4.7.2 (if I remember correctly). I want to use gcc4.8.2 |
# 14:10:59 |
saedelaere |
it offers way more speed and better c++11 support |
# 14:11:04 |
y_morin |
saedelaere: depends what you want to do with the RPi. I ditched the generic distros (such as raspbian) to build my own rootfs using Buildroot. |
# 14:11:37 |
y_morin |
saedelaere: Where raspbian boots in ~45s, my rpi boots in <4s with just what I need. |
# 14:12:27 |
y_morin |
saedelaere: and this is whithout any optimising the system. |
# 14:12:52 |
saedelaere |
wow, 4s seconds sounds great |
# 14:15:08 |
y_morin |
saedelaere: yep. It has network with connman, and runs the tvheadend daemon too. I even have to slow it down a bit, since tvheadend requires the /dev/dvb stuff to be present before launch, but USB is slow at enumerating the devices, so I have a startup script that explicitly waits for them to appear before continuing. That's what is taking the longest in the boot process. |
# 15:04:23 |
hrubi |
joins #crosstool-ng |
# 15:17:13 |
sh4rm4 |
saedelaere, you could also use a musl libc toolchain: https://bitbucket.org/GregorR/musl-cross |
# 15:19:39 |
sh4rm4 |
i hope your cappin fragment is doing well, btw |
# 15:20:34 |
saedelaere |
yeah it suits me well :) |
# 15:21:06 |
sh4rm4 |
because it masks your face ? ;) |
# 15:21:37 |
saedelaere |
sh4rm4: whats the advantage of this musl libc toolchain? looks pretty interesting |
# 15:22:10 |
sh4rm4 |
1) up-to-date 2) reasonable maintainership 3) only a single configuration 4) standards compliant |
# 15:22:33 |
saedelaere |
this sounds really good :9 |
# 15:22:44 |
sh4rm4 |
the thousands wheels and knobs of uclibc make it a PITA to get a working toolchain |
# 15:23:18 |
saedelaere |
the fragment provides the perfect stealth mode for all this NSA shit ;) |
# 15:23:25 |
sh4rm4 |
haha |
# 15:36:44 |
smartin_ |
quits : Quit: leaving |
# 15:44:19 |
saedelaere |
sh4rm4: "For ARM, you must set the triple to arm-linux-musleabi" where do I set this? |
# 15:47:50 |
sh4rm4 |
let me read the README... |
# 15:48:24 |
saedelaere |
oh I thought this is your project. |
# 15:49:06 |
sh4rm4 |
https://github.com/GregorR/musl-cross/blob/master/defs.sh#L68 |
# 15:49:31 |
sh4rm4 |
put TRIPLE=xxx into your config.sh |
# 15:49:58 |
sh4rm4 |
well i am the spiritual father of this project, but not it's author |
# 15:54:59 |
saedelaere |
ehm I am bit confused right now, I do build this cross compiler on my host machine and not on the raspberry pi, correct? again to much hours spend before the computer |
# 15:56:09 |
sh4rm4 |
yes, on your fast x86 host |
# 15:56:28 |
sh4rm4 |
building it on the rpi would take days |
# 16:05:58 |
y_morin |
sh4rm4: saedelaere wants to cross-compile for an existing raspbian distro. So building a toolchain with musl will not work for him/her, at least without dirty hacks with the dynamic linker. |
# 16:06:35 |
sh4rm4 |
thats wrong |
# 16:06:50 |
sh4rm4 |
he can 1) either compile statically or 2) install the musl dynliker |
# 16:07:05 |
sh4rm4 |
there are no dirty hacks needed to use the musl dynlinker |
# 16:07:41 |
sh4rm4 |
it has an own name, so it can perfectly live next to any other libc |
# 16:08:00 |
y_morin |
sh4rm4: well, yes, indeed. |
# 16:09:16 |
y_morin |
sh4rm4: But still, that will be a weird setup if he/she wants to use existing libraries from the system. At least, it does not smell good to mix multiple C libraries. |
# 16:09:23 |
sh4rm4 |
but yes, given that he talked about C++ he probably doesnt intend to build statically |
# 16:09:54 |
sh4rm4 |
because linking libstdc++ statically makes every binary at least 1.5 MB |
# 16:10:17 |
sh4rm4 |
unless you build freestanding, i.e. without usage of std:: |
# 16:11:34 |
y_morin |
quits : Remote host closed the connection |
# 16:11:45 |
sh4rm4 |
y_morin, indeed, having multiple libcs all accessing a shared /lib dir is less than optimal |
# 16:12:10 |
ldm |
quits : Quit: ldm |
# 16:13:08 |
saedelaere |
maybe I should just use archlinux arm on my pi. that should simplify things |
# 16:13:09 |
y_morin |
joins #crosstool-ng |
# 16:13:20 |
sh4rm4 |
y_morin, indeed, having multiple libcs all accessing a shared /lib dir is less than optimal |
# 16:13:40 |
sh4rm4 |
or dynlinkers, for that matter |
# 16:14:02 |
sh4rm4 |
saedelaere, or just get rid of C++ and use The Real Thing - C |
# 16:14:12 |
sh4rm4 |
then cross-compile your apps statically |
# 16:14:34 |
saedelaere |
what are those dynlinkers you are talking about? I couldn't find something so far |
# 16:14:51 |
saedelaere |
no no, I won't use plain C again :) |
# 16:14:58 |
saedelaere |
at least not for this project |
# 16:15:19 |
sh4rm4 |
a dynlinker is the program that starts your dynamically linked binary and makes the necessary runtime symbol relocations |
# 16:15:39 |
sh4rm4 |
it's path is hardcoded into every program's elf header |
# 16:15:52 |
sh4rm4 |
readelf -a mybinary | grep -i interp |
# 16:16:59 |
saedelaere |
I need to access posgres databases, read/write xml files, multithreading. not to mention such nice features like lambdas, c++ smart pointers... |
# 16:17:12 |
sh4rm4 |
nice features ? lol |
# 16:17:25 |
saedelaere |
I like them :) |
# 16:17:32 |
sh4rm4 |
postgres is C btw |
# 16:17:39 |
saedelaere |
damn :) |
# 16:17:45 |
sh4rm4 |
and libpthread is C as well |
# 16:17:50 |
sh4rm4 |
and libxml2 too |
# 16:18:20 |
sh4rm4 |
any good library is C |
# 16:18:29 |
sh4rm4 |
because only C++ can link against C++ |
# 16:18:49 |
saedelaere |
come on, stop now :) Last time I did something in plain C is years ago. You really make me consider this |
# 16:19:28 |
saedelaere |
but currently the musl build process is running |
# 16:19:41 |
sh4rm4 |
(btw you cannot even link against a C++ lib compiled with a different compiler) |
# 16:19:54 |
sh4rm4 |
since the name mangling is not standardized |
# 16:20:40 |
saedelaere |
about dynlinker, so this is the magic about musl? the dynlinker will automagically adress the correct libs on raspbian? |
# 16:20:59 |
sh4rm4 |
uhm... no |
# 16:21:16 |
saedelaere |
I really considered this cross compiling would be much easier |
# 16:21:20 |
sh4rm4 |
you need to tell it where to find the libs |
# 16:21:29 |
sh4rm4 |
and those should all be compiled against musl as well |
# 16:22:00 |
sh4rm4 |
so ideally, you would make a musl-prefix like /usr/local/musl |
# 16:22:31 |
sh4rm4 |
and adapt /etc/ld-musl-arm.conf to point there |
# 16:23:24 |
sh4rm4 |
since dynlinking is complex, it's advisable to statically link when you want to supply a binary that can just be dropped onto any arm/linux box |
# 16:23:41 |
saedelaere |
yep, I will statically link |
# 16:23:56 |
saedelaere |
I don't think I understand this dynlinker :) |
# 16:24:09 |
sh4rm4 |
with glibc, it's even more complicated |
# 16:24:19 |
sh4rm4 |
you need to run ldconfig whenever you install libs |
# 16:25:51 |
saedelaere |
I just compiled the musl cross compiler toolchain |
# 16:26:25 |
saedelaere |
do I have to install anything on the raspberry pi from musl or should statically just work now? |
# 16:37:58 |
sh4rm4 |
statically will just work |
# 16:38:16 |
sh4rm4 |
as long as you compile any needed libs the crosscompiler |
# 16:38:27 |
sh4rm4 |
and install them into the cross-compiler prefix |
# 16:38:46 |
sh4rm4 |
s/any needed libs the crosscompiler/any needed libs with the crosscompiler |
# 16:42:54 |
saedelaere |
this sound like a reasonable task. |
# 16:43:56 |
saedelaere |
thank you all for your help. this really helped me understand some basics! |
# 18:04:28 |
djerome |
joins #crosstool-ng |
# 19:07:44 |
pyromaniac |
parts #crosstool-ng |
# 21:27:00 |
y_morin |
quits : Quit: leaving |
# 22:29:40 |
ben1066 |
is now known as: BenPye |
# 22:47:22 |
BenPye |
is now known as: benpye |
# 22:52:01 |
benpye |
is now known as: ben1066 |