ibotlog2html for #crosstool-ng

<< Previous 2013-11-03 Next >>

# 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: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

Generated by ibotlog2html by Yann E. MORIN