| 00:19.52 | *** join/#edev kergoth (n=kergoth@ip24-255-7-190.tc.ph.cox.net) |
| 02:28.14 | *** join/#edev Madsy (n=madsy@fu/coder/madsy) |
| 03:51.23 | *** join/#edev devilsadvocate_ (n=quassel@115.113.101.148) |
| 04:18.47 | *** join/#edev mbuf (n=user@61.16.248.242) |
| 04:45.56 | *** join/#edev devilsadvocate (n=quassel@115.113.101.148) |
| 04:57.40 | *** join/#edev landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 04:57.40 | *** mode/#edev [+o landley] by ChanServ |
| 05:09.55 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 05:23.35 | *** join/#edev brolin (n=brolin@190.157.14.3) |
| 06:32.07 | *** join/#edev lyakh (n=lyakh@87.189.18.91) |
| 06:32.08 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 06:34.01 | *** join/#edev devilsadvocate (n=quassel@115.113.101.148) |
| 06:35.27 | *** join/#edev redblue (i=star@ppp023.108-253-207.mtl.mt.videotron.ca) |
| 07:00.06 | *** join/#edev linac (n=lin@123.249.160.78) |
| 07:20.38 | *** join/#edev DrZimmerman (n=theo@77-56-240-146.dclient.hispeed.ch) |
| 07:49.52 | *** join/#edev damunix (n=damunix@brc29-1-82-245-194-55.fbx.proxad.net) |
| 07:53.00 | *** join/#edev florian (n=fuchs@f049171179.adsl.alicedsl.de) |
| 09:05.18 | *** join/#edev onnoval (n=sam@123.252.146.52) |
| 09:08.46 | *** join/#edev harpal (n=Harpal@121.246.75.165) |
| 10:33.59 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 10:46.50 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 11:16.40 | *** join/#edev like|zzz (n=chatzill@82-171-51-231.ip.telfort.nl) |
| 11:27.29 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:32.36 | *** join/#edev florian (n=fuchs@f049171179.adsl.alicedsl.de) |
| 12:20.36 | *** join/#edev damunix (n=damunix@ARennes-551-1-49-54.w92-135.abo.wanadoo.fr) |
| 12:35.28 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 12:35.36 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:06.09 | *** join/#edev pirho_ (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 14:07.19 | *** join/#edev Othello (i=Othello@gateway/tor/x-a6caf0081f2d093d) |
| 14:34.58 | *** join/#edev Seb_2010 (n=chatzill@118.203.29.231) |
| 14:47.26 | *** join/#edev Othello (i=Othello@gateway/tor/x-76d111f97b064ce6) |
| 14:54.32 | *** join/#edev brolin (n=brolin@201.232.58.220) |
| 15:16.35 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 15:41.00 | *** join/#edev likewise (n=chatzill@82-171-51-231.ip.telfort.nl) |
| 16:10.53 | *** join/#edev brolin (n=brolin@201.232.58.220) |
| 16:32.11 | *** join/#edev florian (n=fuchs@f049171179.adsl.alicedsl.de) |
| 17:13.22 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 17:37.20 | *** join/#edev Magorium (i=Othello@gateway/tor/x-7143876cb7748301) |
| 18:59.34 | *** join/#edev rektide (n=devnull@209.111.90.131) |
| 19:07.37 | *** join/#edev udda (n=a@node-12047.tor.pppoe.execulink.com) |
| 19:14.42 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 19:14.42 | *** mode/#edev [+o GPSFan] by ChanServ |
| 19:15.01 | *** join/#edev damunix (n=damunix@ARennes-551-1-11-144.w92-129.abo.wanadoo.fr) |
| 19:23.09 | *** join/#edev roxfan2 (n=dunno@4.163-244-81.adsl-dyn.isp.belgacom.be) |
| 19:28.11 | *** join/#edev landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 19:28.11 | *** mode/#edev [+o landley] by ChanServ |
| 19:45.44 | *** join/#edev Madsy (n=madsy@fu/coder/madsy) |
| 20:12.36 | *** join/#edev damunix (n=damunix@ARennes-551-1-120-240.w92-139.abo.wanadoo.fr) |
| 20:39.28 | *** join/#edev ja2 (n=marcus@81-233-153-207-no83.tbcn.telia.com) |
| 20:46.59 | ja2 | Pardon my ignorance: arm-elf-gcc or arm-linux-gcc? What is the difference? |
| 20:52.20 | landley | ja2: default header and library search paths. |
| 20:52.35 | landley | If you run arm-linux-gcc --nostdinc --nostdlib you're more or less running arm-elf-gcc. |
| 20:52.42 | landley | (Slight oversimplification, but you get the idea.) |
| 20:52.53 | landley | Not sure how crt1.o and friends work in there. |
| 20:52.57 | ja2 | landley: So, arm-elf wouldnt find linux librarys without pointing them out. Or can use at all? |
| 20:53.11 | ja2 | s/can/cant |
| 20:53.22 | landley | Won't find them unless you point them out, I believe. |
| 20:53.32 | landley | It doesn't depend on an existing installed C library, for one thing. |
| 20:53.56 | ja2 | Hmm, ok. So I have this dev board with preloaded linux, I go for arm-linux (kind of obvious). |
| 20:54.20 | landley | See http://impactlinux.com/hg/firmware/file/tip/sources/toys/ccwrap.c for a wrapper that adds all the stuff back in explicitly on the command line. |
| 20:54.47 | landley | If you're wondering what exactly all the things you need to _have_ on the standard command line are, that might help. Also "gcc -v". |
| 20:54.57 | ja2 | With that wrapper you stay with arm-elf all the time? |
| 20:55.05 | landley | In theory you can. I haven't tried it. |
| 20:55.32 | landley | Mostly I build arm-unknown-linux and just don't provide it a C library until afterwards.. |
| 20:55.52 | landley | It hardwires in a lot of defaults, which the wrapper then tells it to ignore. Probably not the cleanest solution, but it works and works reliably, so I haven't fiddled with it... |
| 20:56.06 | ja2 | Its pretty more complex cross compiling than compiling a console app. :) |
| 20:56.12 | landley | As I said, the only thing I'd worry about is whether you get crtbegin.o and crtend.o and such. |
| 20:56.29 | landley | Some of those come from the C library, some from the compiler, and I always have to look it up to remember which is which. |
| 20:56.37 | landley | Yup. |
| 20:56.54 | landley | http://landley.net/writing/docs/cross-compiling.html |
| 20:57.12 | landley | That's old, I need to rewrite it... |
| 20:57.24 | ja2 | Prefect! I always though compiling to be more difficult than programming. |
| 20:57.45 | landley | Also you can just grab a prebuilt cross compiler from http://impactlinux.com/fwl/downloads/binaries if you're feeling lazy. :) |
| 20:57.59 | landley | I believe solar wrote scripts that create them too, for gentoo-embedded. |
| 20:58.33 | landley | In this case, probably http://impactlinux.com/fwl/downloads/binaries/cross-compiler/host-i686/cross-compiler-armv5l.tar.bz2 |
| 20:59.08 | landley | Although that's uClibc 0.9.30.1, so if your target is glibc or an older uClibc, you'd need to statically link unless you're building a whole new target. |
| 20:59.24 | ja2 | Neat. x86_64 and i686, thats the compiling PC, not the arm processor, right? |
| 20:59.31 | landley | That's the host system, yeah. |
| 20:59.34 | udda | is it possible to statically link in libstdc++ and any other dependencies to generate a c++ program |
| 20:59.50 | landley | udda: yes, although I'd recommend uClibc++ instead. :) |
| 21:00.15 | landley | I'm working right now on cross compilers that include uClibc++. The ones I just linked to don't. (They have a g++ compiler, but not a g++ standard library.) |
| 21:00.34 | udda | whats the problem of statically linking in the normal stdc+= |
| 21:00.35 | landley | But libstdc++ is a library, you can statically link against it the way you can other libraries. |
| 21:00.37 | udda | libstdc++* |
| 21:00.45 | landley | Warning: the result is going to be _flipping_huge_ with the standard gnu libraries. |
| 21:00.52 | landley | Size. |
| 21:01.22 | udda | i see |
| 21:01.32 | udda | ok well, i'm going to build uclibc++ then |
| 21:01.33 | landley | I don't _think_ it has the funky "even though you statically linked, libnss.so is still a shared library it needs via dlopen because pam is evil) kind of thing. |
| 21:01.50 | landley | uClibc++ is a nice little library, but it's an _amazing_ pain to compile the sucker. |
| 21:01.54 | udda | heh |
| 21:02.28 | udda | can i compile it on the target system itself |
| 21:02.55 | ja2 | I think starting to try out arm would be alot easier if you had the toolchain served on a silver plate. (Well, I almost got it now) |
| 21:03.09 | landley | phone, just a sec... |
| 21:03.57 | landley | udda: I built a ystem so you can compile stuff under qemu. |
| 21:04.06 | landley | http://impactlinux.com/fwl |
| 21:04.27 | landley | Built a native toolchain and a little root filesystem with make and bash and such to act as a development environment. |
| 21:04.43 | landley | The advantage of doing it under qemu is you can use all the memory and disk space you want. |
| 21:04.57 | udda | yeah |
| 21:04.59 | udda | im using qemu |
| 21:05.05 | udda | i have it running mipsel right now |
| 21:05.18 | landley | Plus your host processor usually so much faster than the target device that even with the cost of the emulator you still come out slightly ahead. |
| 21:05.37 | landley | http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-mipsel.tar.bz2 |
| 21:06.01 | udda | well, i already have it running some debian linux on mipsel currently |
| 21:06.09 | landley | That works too. :) |
| 21:06.13 | landley | Yes, you can build natively under qemu. |
| 21:06.13 | udda | so i just download the uclibc++ and just make? |
| 21:06.28 | landley | More or less; make menuconfig first. |
| 21:06.50 | landley | The tricky bit is you have to grab libsupc++.a off the host, but if you've already got libstdc++ built it should be there. |
| 21:07.09 | landley | (It's an interface library that contains things like the stack unwinding code.) |
| 21:07.13 | udda | right |
| 21:07.19 | ja2 | is uclibc installed on the cross compiling PC or the dev. platform? |
| 21:07.29 | udda | how do i confirm i have libstdc++ built already |
| 21:07.30 | landley | Which can vary depending on whether you configured your compiler for sjlj or dwarf2, whether or not you enabled thread support, etc... |
| 21:07.50 | udda | g++ -v? |
| 21:08.15 | landley | If g++ can build a "hello world" that uses the cout << stuff, then libsupc++ got built. |
| 21:08.28 | landley | It's the c++ equivalent of libc.so. |
| 21:08.35 | landley | Er, libstdc++ I mean. |
| 21:08.49 | landley | Probably "find / -name libsupc++.a" would also do it too. |
| 21:08.49 | udda | ok yeah, i can build hello world fine |
| 21:10.03 | udda | so if i link to uclibc++, i can run it on the target system without getting any of those "can't load library libstdc++.so.6" and other dynamic linking errors? |
| 21:15.10 | landley | Statically link, yes. |
| 21:15.24 | landley | You could also statically link to libstdc++, you'd just add maybe a megabyte to your executable. |
| 21:15.33 | landley | You could also actually install libstdc++ on the target. :) |
| 21:15.45 | landley | Or libuClibc++.so. |
| 21:16.18 | landley | Well, actually libstdc++ depends on libc.so.6, so if you used libstdc++ you'd need glibc too. (Built for the target.) |
| 21:16.36 | landley | uClibc++ is probably your best bet, built against uClibc. |
| 21:16.42 | udda | heh |
| 21:17.10 | udda | well, i did statically linnk against libstdc++ an hour or so ago and ran it on the target |
| 21:17.17 | udda | but it gave another link error |
| 21:17.21 | udda | about libgcc_s.so.1 |
| 21:17.22 | landley | What error? |
| 21:17.22 | udda | or something |
| 21:17.26 | landley | Ah yes. |
| 21:17.38 | landley | Try --static-libgcc |
| 21:17.45 | landley | You'd thing normal --static would specify that... |
| 21:18.23 | udda | i think i had tried with that on |
| 21:18.26 | udda | oh yeah |
| 21:18.31 | udda | i got "User defined signal 1 |
| 21:18.35 | landley | libgcc_s.so.1 contains stuff like code for 64 bit division on 32 bit hosts. |
| 21:18.36 | udda | wheni ran the program |
| 21:18.45 | landley | Ok, that one I don't know. |
| 21:18.58 | landley | Could be an "illegal instruction" error, could be an endianness mismatch... |
| 21:19.32 | landley | The simplest program you can run isn't actually "hello world", it's false. |
| 21:19.41 | landley | Make a program that returns 42, and then check $? after you run it. |
| 21:19.58 | landley | That tests the startup and shutdown code, primarily. crtbegin.o, crt1.o, and so on. |
| 21:20.10 | landley | And of course that your compiler is producing the correct code. |
| 21:20.46 | udda | well, i did that stuff using the cross compiler toolchain |
| 21:21.04 | udda | if i try to use -static-libgcc on the qemu |
| 21:21.09 | landley | Yup. Build a statically linked "false" using the cross compiler toolchain and see if that gives you the same segfault. |
| 21:21.11 | udda | it still produces a 10kb |
| 21:21.15 | udda | instead of statically linking it in |
| 21:21.23 | landley | Run ldd against the resulting binary. |
| 21:21.30 | landley | Also, try two dashes. --static-libgcc |
| 21:21.35 | landley | What gcc version is it, by the way? |
| 21:21.38 | udda | yeah sorry, i had used 2 dashes |
| 21:22.01 | udda | gcc 4.1.2 |
| 21:22.10 | udda | Target: mipsel-linux-gnu |
| 21:26.54 | landley | I'm using 4.1.2 as well. |
| 21:27.01 | landley | target mipsel-unknown-linux |
| 21:28.08 | udda | is that your cross compiler gcc or the one in qemu |
| 21:30.37 | landley | both. |
| 21:30.53 | landley | Although in the relese versions I've only been building uClibc++ in the native compiler. |
| 21:31.09 | landley | I'm adding it to the cross compiler in the development version now. |
| 21:31.13 | landley | As I said, building it is fiddly. |
| 21:32.55 | udda | ok, so i just compiled on the native system, statically linking libstd++ |
| 21:32.57 | udda | about 1mb |
| 21:33.17 | udda | im going to try this on the target |
| 21:34.16 | landley | ok |
| 21:39.08 | udda | for some reason, when i build the app in qemu and run it there, it works fine |
| 21:39.16 | udda | but if when i wget to the target |
| 21:39.26 | udda | and i do ./a.out |
| 21:39.36 | udda | it says no such file or directory |
| 21:39.37 | udda | but its there |
| 21:39.37 | udda | heh |
| 21:42.32 | udda | i run ldd on the 1mb a.out and the result is |
| 21:42.46 | udda | libm.so.6 => /lib/libm.so.6 (0x2ab00000) |
| 21:42.53 | udda | libc.so.6 => ... |
| 21:43.17 | udda | - /lib/ld.so.1 ... |
| 21:45.09 | *** join/#edev Madsy (n=madsy@fu/coder/madsy) |
| 21:45.24 | udda | any idea landle? |
| 21:45.26 | udda | landley* |
| 21:47.45 | *** join/#edev kergoth (n=kergoth@ip24-255-7-190.tc.ph.cox.net) |
| 21:49.35 | *** part/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 22:11.18 | landley | Your cross compiler is using libc.so.6. |
| 22:11.27 | landley | And you're not statically linking. |
| 22:11.54 | landley | It may be trying to statically link, but it's not succeeding. |
| 22:12.07 | landley | Check and see if you have a libm.a, by the way. |
| 22:12.20 | *** join/#edev brolin (n=brolin@201.232.58.220) |
| 22:12.30 | landley | Why is hello world linking against libm anyway? Probably libstdc++... |
| 22:15.37 | udda | yeah i have both libm.a and libc.a in my /usr/lib |
| 22:15.40 | udda | in qemu |
| 22:16.20 | landley | do g++ -v and look at the collect2 line. |
| 22:17.14 | udda | hmm, don't see a collect2 line |
| 22:17.24 | landley | Is there an ld line? |
| 22:17.38 | landley | collect2 is a wrapper for ld that exists to break stuff. |
| 22:17.50 | landley | That's not _quite_ a complete explanation, but it's a distressingly accurate one. |
| 22:18.10 | g1powermac_PB | heh |
| 22:18.13 | udda | http://rafb.net/p/ztQneX10.html |
| 22:20.00 | landley | udda: no, you have to add -v to the actual compilation. If it's not doing anything, you won't see what it's doing. |
| 22:20.15 | udda | oh verbose |
| 22:20.16 | landley | g++ -v hello.cpp -static |
| 22:20.18 | landley | Yup. |
| 22:25.32 | udda | oooooooh |
| 22:25.35 | udda | nice it works |
| 22:25.38 | udda | i didnt use -static before |
| 22:26.05 | udda | i just had g++ hello.cpp -lstdc++ |
| 23:29.46 | *** join/#edev dijenerate (n=dijenera@64.210.41.159) |
| 23:36.53 | landley | udda: yeah, -static is kind of needed there. :) |
| 23:37.16 | landley | You shouldn't have to say -lstdc++ any more than you have to say -lc. |
| 23:37.28 | landley | The compiler does that for you, built-in. Unless you say -nostdlib. |
| 23:42.19 | udda | good stuff, thanks for the help |
| 23:45.59 | landley | You're welcome. |