| # 01:07:50 | kpet | quits : Ping timeout: 252 seconds |
| # 03:23:39 | mnt_real | quits : Quit: Leaving |
| # 09:56:23 | y_morin | joins #crosstool-ng |
| # 10:35:32 | esbenh | what is the opinion on adding a patch for re-enabling RPC support in glibc 2.14? |
| # 10:36:15 | esbenh | as I understand it, ti-rpc simply is not ready as a viable replacement yet, leaving glibc 2.14+ practically useless in a larger context |
| # 10:37:12 | esbenh | I took a patch like that from eglibc 2.14 recipe of OE |
| # 10:37:46 | esbenh | works nicely with glibc 2.14 with reformatting |
| # 10:48:53 | y_morin | is now known as: y_morin|away |
| # 12:05:38 | smartin | joins #crosstool-ng |
| # 12:22:27 | y_morin|away | is now known as: y_morin |
| # 12:23:28 | y_morin | esbenh: I have no strong opinion for or against. |
| # 12:24:20 | y_morin | esbenh: Of course, this would be a workaround, not a fix. |
| # 12:25:01 | y_morin | esbenh: The proper fix would be to either beat the glibc folks to revise their position, or to get ti-rpc up-to-speed. |
| # 12:47:48 | esbenh | hehe, I agree. But... |
| # 12:48:43 | esbenh | I don't have time or motivation to help ti-rpc get up to speed, and I don't envision anyone being able to change the position of the glibc folks, at least not mr. drepper |
| # 13:03:31 | y_morin | is now known as: y_morin|away |
| # 13:06:16 | kos_tom | it is kind of amazying to remove the RPC support from glibc if ti-rpc is not ready |
| # 13:49:19 | smartin | quits |
| # 14:46:00 | esbenh | even it it was ready, it is a different api, so completely dropping sunrpc is a rather drastic approach. |
| # 14:58:09 | y_morin|away | is now known as: y_morin |
| # 14:58:37 | y_morin | kos_tom: heya! |
| # 14:58:50 | y_morin | kos_tom: I've looked at linking statically against libpython. |
| # 14:59:09 | y_morin | kos_tom: seems there are abunch of issues doing so. |
| # 14:59:34 | kos_tom | ah ah ? |
| # 15:00:14 | y_morin | kos_tom: lemme dig up the pointers I found yesterday... |
| # 15:00:41 | y_morin | kos_tom: 1st one: http://comments.gmane.org/gmane.comp.gdb.devel/30708 |
| # 15:02:08 | y_morin | kos_tom: 2nd one: http://sourceware.org/ml/gdb/2010-01/msg00223.html |
| # 15:02:29 | y_morin | that 2nd one says "Static linking may be a problem." |
| # 15:03:52 | y_morin | kos_tom: probably we could work it around, or probably later versions behave better, but it does not look as easy as just adding -static to the linker flags |
| # 15:04:09 | kos_tom | another option would be to build dynamically against python (and maybe gmp, mpfr, etc.) and build the gcc, gdb and al. binaries with an rpath |
| # 15:04:37 | y_morin | kos_tom: don't talk to me about rpath. I don't want to hear about it. rpath is evil. |
| # 15:04:42 | y_morin | :-) |
| # 15:04:43 | kos_tom | if you add -static to the link flags, it builds it completely statically (even against glibc). I think linking statically against libpython is enough. |
| # 15:04:48 | kos_tom | y_morin: I don't understand why. |
| # 15:05:00 | kos_tom | for what ct-ng is doing, rpath is really a good option. |
| # 15:05:16 | y_morin | kos_tom: if you use rpath, you can't relocate. |
| # 15:05:20 | kos_tom | yes you can |
| # 15:05:30 | kos_tom | ever heard of $ORIGIN ? |
| # 15:05:48 | y_morin | kos_tom: Ah, yes. $ORIGIN. |
| # 15:06:17 | kos_tom | with $ORIGIN, you can relocate. The libs just need to be at some fixed location relative to the binaries, but this isn't a problem. |
| # 15:07:09 | kos_tom | the fact that gdb isn't linked statically against libpython makes it practically completely useless to link gcc statically against mpfr/ppl/gmp, because it means that you can't move the toolchain to a different host. |
| # 15:07:54 | y_morin | kos_tom: the static gmp/mpfr/ppl/... is not originally about moving across hosts, but to ease relocatability. |
| # 15:08:06 | y_morin | kos_tom: it is to avoid needing LD_LIBRARY_PATH. |
| # 15:08:48 | y_morin | kos_tom: but don't get me wrong! I do agree that crossing host-boundary can be useful. |
| # 15:08:59 | y_morin | *usefull. |
| # 15:10:01 | y_morin | kos_tom: there's nothing about @ORIGIN in my ld man page. There is a reference to 'origin' in the -z option, but not in the -rpath opiton. |
| # 15:10:34 | kos_tom | man ld.so |
| # 15:10:48 | kos_tom | $ORIGIN |
| # 15:10:48 | kos_tom | ld.so understands the string $ORIGIN (or equivaâ |
| # 15:10:48 | kos_tom | lently ${ORIGIN}) in an rpath specification to |
| # 15:10:48 | kos_tom | mean the directory containing the application |
| # 15:10:49 | kos_tom | executable. |
| # 15:10:55 | y_morin | Ah, good. |
| # 15:11:19 | kos_tom | but as you don't build libpython, you would have to copy the host libpython.so there. |
| # 15:11:46 | kos_tom | another option is to try to link statically against libpython.a, see what the problems are and see if it's doable to fix them. |
| # 15:11:50 | y_morin | kos_tom: indeed. And I do *not* want to build libpython. :-) |
| # 15:12:07 | y_morin | kos_tom: indeed. That's what I've started... |
| # 15:12:20 | kos_tom | great! |
| # 15:13:04 | y_morin | kos_tom: I was just saying there's a not-completely-paved-yet road ahead... |
| # 15:14:27 | y_morin | kos_tom: and embedding the host libpython.so is not really an option either. It has dependencies: openssl, libz. |
| # 15:15:52 | y_morin | kos_tom: quote from a stack-overflow post: "Whoever decided to make the token $ORIGIN is an evil bastard who deserves a special place in programmer hell." |
| # 15:15:56 | y_morin | Lol! :-) |
| # 15:19:16 | kos_tom | :) |
| # 15:19:49 | y_morin | kos_tom: do you know if the $ORIGIN trick works with uClibc's ld.so ? |
| # 15:37:57 | kos_tom | I am not sure. |
| # 15:39:56 | y_morin | kos_tom: looks like not. I've looked at the code, and there are references to it, but no actual use of the #defined values... |
| # 15:40:33 | kos_tom | yeah, same conclusion her. |
| # 15:40:52 | kos_tom | but do you expect people to run ct-ng generated toolchains on uclibc based hosts ? |
| # 15:41:49 | y_morin | kos_tom: Yes, I do. I'm planning to do so in a short time. If I can get enough free time... |
| # 15:44:57 | y_morin | But that's not a show-stopper for now! |
| # 15:45:22 | kos_tom | ok, I'm leaving. |
| # 15:45:50 | y_morin | See ya! |
| # 16:41:36 | smartin | joins #crosstool-ng |
| # 17:09:48 | y_morin | is now known as: y_morin|away |
| # 18:46:02 | smartin | quits |
| # 19:58:18 | y_morin|away | is now known as: y_morin |
| # 20:14:40 | kos_tom | y_morin: have you found any solution? |
| # 20:15:16 | y_morin | kos_tom: not really worked on it since last time we spoke... I just came back after dinner. |
| # 20:16:14 | kos_tom | ok. |
| # 20:16:15 | y_morin | kos_tom: and I have a bunch of pending patches I have to handle first ( contributors deserve a bit of my time, don't they? :-) ) |
| # 20:18:01 | y_morin | kos_tom: Something that just sprung to my mind: there's already the "static toolchain" config option, which builds a totally staticaly linked toolchain. |
| # 20:18:20 | y_morin | kos_tom: Maybe that's what should be used by people that want to move a toolchain across hosts... |
| # 20:19:26 | y_morin | kos_tom: My reasonning here, is that if one needs to move the toolchain, one knows that fact, and acts accordingly; that is, set "static toolchain". |
| # 20:35:39 | kos_tom | y_morin: but does it build statically against libpython ? |
| # 20:35:44 | kos_tom | (and does it work) ? |
| # 20:36:04 | kos_tom | but IMO, it'd be great to be able to build dynamically against the C library and statically against everything else. |
| # 20:36:19 | kos_tom | that's how CodeSourcery toolchain work, as far as I can understand. |
| # 20:42:33 | y_morin | kos_tom: http://code.bulix.org/a8x6uv-80667 |
| # 20:42:42 | y_morin | kos_tom: python is not supported in CS toolchains. |
| # 20:48:23 | kos_tom | really ? I had the feeling that in recent versions of gdb, python was mandatory to do some remote debugging, because the target descriptions are written in XML and parsed using Python. |
| # 20:48:50 | kos_tom | at least, in our training sessions, when gdb is built without python support, remote debugging support doesn't work ("remote g packet too long") |
| # 20:49:12 | y_morin | kos_tom: well, that's what it says in the snippet I pasted above... |
| # 20:49:23 | kos_tom | yeah, I see. |
| # 20:49:53 | y_morin | kos_tom: I have to admit it's been quite some time I needed remote debugging... |
| # 20:49:57 | kos_tom | aah noo, sorry. |
| # 20:50:06 | kos_tom | it's when expat is not detected that there is a problem. |
| # 20:50:12 | kos_tom | which looks more logical. |
| # 20:50:15 | y_morin | kos_tom: Ah, ah! |
| # 20:50:26 | kos_tom | see my email on the crossgcc list Mon, 25 Jul 2011 12:07:09 +0200 |
| # 20:50:28 | y_morin | kos_tom: IIRC, python is for pretty-printing stuff... |
| # 20:50:43 | kos_tom | y_morin: would it be possible to have a ct-ng option to build without python support ? |
| # 20:50:56 | y_morin | kos_tom: definitely, yes. |
| # 20:50:56 | kos_tom | (I guess you'll say: send a patch :-) ) |
| # 20:51:29 | y_morin | kos_tom: actually, I was going to say: well, hm... Err... Lemme see... |
| # 20:51:31 | y_morin | ;-) |
| # 20:53:14 | kos_tom | --with-python=no ? |
| # 20:53:28 | y_morin | kos_tom: yes, seems like it. |
| # 20:54:02 | y_morin | kos_tom: it can also be used to point to an alternate python (executable or install prefix) |
| # 20:54:50 | kos_tom | hm, gdb also depends on expat, so it should also be statically linked against expat |
| # 20:55:40 | y_morin | kos_tom: well, mine also links to openssl (libssl.so) |
| # 20:56:00 | y_morin | kos_tom: and ncurses, and libz. |
| # 20:56:45 | y_morin | kos_tom: http://code.bulix.org/1ob4hg-80668 |
| # 21:04:29 | y_morin | kos_tom: what about: http://code.bulix.org/7bf8t7-80669 |
| # 21:09:00 | kos_tom | yeah, sounds good. |
| # 21:09:49 | kos_tom | the cs gdb is dynamically linked against ncurses, but seems to be linked statically against expat and all other libraries. |
| # 21:16:59 | ccct | y_morin: Any new insight on why compiling glib-ports loops on ubuntu? (problem from 2 days ago) |
| # 21:18:02 | y_morin | is now known as: y_morin|away |
| # 21:18:31 | y_morin|away | is now known as: y_morin |
| # 21:18:44 | y_morin | ccct: no, not yet... |
| # 21:19:10 | y_morin | kos_tom: indeed. |
| # 21:32:41 | y_morin | ccct: what version of ubuntu was it failing in ? |
| # 21:33:07 | y_morin | ccct: can you pastebin your /etc/apt/sources.list, please? |
| # 21:34:18 | ccct | y_morin: old intrepid |
| # 21:34:39 | y_morin | ccct: i386 or amd64 ? |
| # 21:35:20 | ccct | i386 |
| # 21:36:42 | y_morin | Arg. Intrepid is no longer avail on archive.ubuntu.com Sigh... |
| # 21:38:14 | y_morin | ccct: can you pastebin your /etc/apt/sources.list please? |
| # 21:38:28 | ccct | http://crosstool-ng.org/download/ibot-logs/2011-07-03.html |
| # 21:38:35 | ccct | That guy was using kubuntu 11.04 |
| # 21:38:46 | ccct | http://pastebin.com/HNMGkUmp < sources.list |
| # 21:39:12 | y_morin | ccct: Ah, old-releases, it is... |
| # 21:40:00 | y_morin | OK, debootstrap-ing in progress... |
| # 22:17:16 | y_morin | kos_tom: how did you manage your 32-bit chroot on your 64-bit machine, in the end? |
| # 22:56:59 | y_morin | quits : Quit: Night... Sleep... |
| # 23:48:21 | mnt_real | joins #crosstool-ng |