| # 00:20:57 | codyps | quits : Ping timeout: 260 seconds |
| # 00:37:08 | devcoder | joins #crosstool-ng |
| # 00:54:25 | devcoder | quits : Quit: devcoder |
| # 00:55:20 | codyps | joins #crosstool-ng |
| # 01:18:19 | codyps1 | joins #crosstool-ng |
| # 01:21:08 | codyps | quits : Ping timeout: 268 seconds |
| # 01:56:14 | codyps1 | quits : Quit: Leaving. |
| # 03:15:54 | redengin | quits : Ping timeout: 252 seconds |
| # 03:20:02 | redengin | joins #crosstool-ng |
| # 04:09:35 | ChanServ | quits : *.net *.split |
| # 04:50:02 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it! |
| # 07:17:36 | sh4rm4 | quits : Ping timeout: 276 seconds |
| # 08:07:03 | ChanServ | joins #crosstool-ng |
| # 08:33:26 | ChanServ | quits : shutting down |
| # 08:34:07 | ChanServ | joins #crosstool-ng |
| # 08:51:43 | smartin | is now known as: smartin|away |
| # 09:02:20 | Net147 | joins #crosstool-ng |
| # 09:12:27 | sspiff | joins #crosstool-ng |
| # 09:12:28 | sspiff | quits : Changing host |
| # 09:12:28 | sspiff | joins #crosstool-ng |
| # 09:23:35 | sspiff | quits : Remote host closed the connection |
| # 10:05:02 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more? |
| # 10:05:07 | y_morin | joins #crosstool-ng |
| # 13:05:27 | sh4rm4 | joins #crosstool-ng |
| # 14:35:33 | smartin|away | is now known as: smartin |
| # 14:55:02 | redengin | success, using the new build had to turn on shared-libs to get ncsd to compile but now its done! |
| # 16:02:05 | andreas_schmidt | joins #crosstool-ng |
| # 16:03:01 | andreas_schmidt | quits : Client Quit |
| # 16:04:44 | andreas_1707 | joins #crosstool-ng |
| # 16:05:51 | andreas_1707 | parts #crosstool-ng |
| # 19:07:37 | devcoder | joins #crosstool-ng |
| # 20:27:59 | devcoder | quits : Quit: devcoder |
| # 21:08:39 | kratz00 | joins #crosstool-ng |
| # 21:27:14 | kratz00 | hi |
| # 21:27:30 | y_morin | kratz00: hello! |
| # 21:27:34 | kratz00 | i have the same problem like him: http://www.digipedia.pl/usenet/thread/12142/15087/ |
| # 21:27:54 | kratz00 | any ideas? |
| # 21:29:13 | y_morin | kratz00: Error: open CFI at theend of file; missing .cfi_endproc directive |
| # 21:29:23 | y_morin | kratz00: that one is known. Lemme remember... |
| # 21:30:15 | Juv1228 | y_morin, did you ever look at this patch? http://sourceware.org/ml/crossgcc/2012-08/msg00061.html |
| # 21:31:21 | Juv1228 | or this one http://sourceware.org/ml/crossgcc/2012-08/msg00043.html |
| # 21:31:29 | y_morin | Juv1228: nope, I missed it (august were holidays). Sorry. |
| # 21:32:02 | Juv1228 | ah, no problem. glad i brought it up then heh |
| # 21:32:39 | y_morin | Juv1228: yes! ;-) Can you ping them on the list (msg with a single "Ping?" for each of your patches) ? |
| # 21:32:55 | y_morin | That will just make them pop into view ;-) |
| # 21:33:03 | y_morin | *into my view |
| # 21:33:06 | kratz00 | here is the exact message i got: http://nopaste.info/b1a04ab345.html |
| # 21:33:49 | y_morin | kratz00: Yep, almost the same. I'm looking for the resolution for this issue. Just a minute... |
| # 21:35:09 | y_morin | kratz00: Oh yes, I get it! :-) Older glibc used a construct that was OK with older binutils, but is not with newer binutils. |
| # 21:35:21 | y_morin | kratz00: what version of binutils are you using? |
| # 21:35:39 | Juv1228 | y_morin, done for both |
| # 21:35:51 | y_morin | Juv1228: Thanks for your patience! ;-) |
| # 21:39:26 | Juv1228 | [PATCH] [CT_NG] [config] [scripts] fix download options < that patch is probably more subjective than my other one |
| # 21:40:30 | kratz00 | y_morin 2.22 |
| # 21:41:08 | y_morin | kratz00: OK, that explains it, then. glibc 2.10 (which you're using) is "too old". Use a more recent version. |
| # 21:41:23 | y_morin | kratz00: or downgrade your binutils to before 2.20. |
| # 21:41:47 | kratz00 | actually it's glibc 2.9 i am trying to build |
| # 21:42:18 | y_morin | kratz00: your build.log says otherwise: Leaving directory `/tmp/try2/.build/src/glibc-2.10.1' |
| # 21:42:19 | kratz00 | y_morin which is the minimum glibc version i can build with 2.22? |
| # 21:42:57 | kratz00 | y_morin doh, you are right, sry :) |
| # 21:43:03 | y_morin | kratz00: not sure. Why would you not want to use the latest? |
| # 21:44:34 | kratz00 | portability, i am trying to build x86 binaries for Linux |
| # 21:46:44 | y_morin | kratz00: so, why not use the latest? What is the restriction for using an old version of glibc? Do you have a binary blob of hell that requires that version? |
| # 21:47:57 | kratz00 | no, but if a build a binary which requires a recent glibc then everybody needs at least this version too |
| # 21:48:34 | Juv1228 | no? |
| # 21:48:48 | Juv1228 | the glibc version you are building will be distributed with your toolchain |
| # 21:48:56 | Juv1228 | and built for the target, not the host |
| # 21:49:39 | Juv1228 | if you want to distribute a single binary for many distro's you should build a static toolchain |
| # 21:50:22 | y_morin | kratz00: you mean, you want to install it on existing distros ? |
| # 21:50:43 | y_morin | kratz00: As Juv1228 said. ;-) |
| # 21:50:53 | kratz00 | y_morin not the toolchain itself, but the binary build with the toolchain |
| # 21:51:35 | kratz00 | i can link everythink statically because of license issues |
| # 21:51:52 | y_morin | kratz00: you meant "can't", right? |
| # 21:52:17 | kratz00 | right |
| # 21:52:23 | kratz00 | sry :) |
| # 21:52:53 | Juv1228 | well, in that case you will either need to back down the binutils version or require a new version of glibc |
| # 21:53:16 | y_morin | kratz00: As Juv1228 just said. :-) |
| # 21:54:29 | kratz00 | and we are back at my initial question, if you know what the min. glibc version is which i can build with binutils 2.22 :) |
| # 21:54:43 | Juv1228 | its not the best option, but you could also distribute the glibc.so with your project |
| # 21:56:06 | y_morin | kratz00: you should first decide on what is the 9oldest glibc you want to support. Then you should use a binutils of that era. |
| # 21:56:39 | kratz00 | y_morin i think this is the best approach |
| # 21:56:42 | y_morin | kratz00: eg. you can stick to glibc-2.10.1, but then you look at its release date, and use a binutils that was released just before. |
| # 21:56:54 | kratz00 | thanks everyone |
| # 21:57:01 | y_morin | kratz00: Cheers! ;-) |
| # 21:58:21 | Juv1228 | y_morin, i also had a few ideas i wanted to run by you quickly |
| # 21:58:31 | y_morin | Juv1228: Shoot! ;-) |
| # 21:59:09 | y_morin | smartin: I am beginning to feel schyzonphreniac, following discussions on two channels at a time! ;-) |
| # 21:59:10 | Juv1228 | the way we are using ct-ng is as a submodule in our git repo combine with some patches/sample's and a wrapper makefile to tie it all together |
| # 21:59:50 | Juv1228 | the biggest issue i have right now is some options are not saved in sample configs |
| # 21:59:58 | Juv1228 | or rather are reverted to the default before being saved |
| # 22:00:08 | y_morin | Juv1228: what options? |
| # 22:00:26 | Juv1228 | one i know for sure is the tarball directory |
| # 22:00:32 | Juv1228 | which is logical to reset |
| # 22:00:54 | y_morin | Juv1228: does it happen if you run ct-ng on its own? |
| # 22:01:12 | Juv1228 | but my idea was to have something along the lines of a .local-config that would be merged with a sample's configuration upon loading it |
| # 22:01:49 | Juv1228 | the issues is with ct-ng saveconfig |
| # 22:01:51 | Juv1228 | i think |
| # 22:03:07 | Juv1228 | http://crosstool-ng.org/hg/crosstool-ng/file/de4120991433/scripts/saveSample.sh.in#l78 |
| # 22:03:22 | y_morin | Juv1228: yes, I was looking at that exact same line. |
| # 22:03:52 | Juv1228 | basically whatever i set to CT_LOCAL_TARBALLS_DIR in my config gets reset to the default in the sample config |
| # 22:04:17 | Juv1228 | and what we are doing is trying to contain everything ct-ng does in a local tree (our git repo) |
| # 22:04:29 | Juv1228 | so its abit easier to manage some aspects |
| # 22:04:40 | kratz00 | quits : Quit: Leaving |
| # 22:04:53 | y_morin | Juv1228: The idea behind saveconfig is for the saved samples to be useable as-is by anyone on their machine, without requiring special provileges, hence paths are all saved as pointing to sub-dirs in ${HOME}, because that's the only place that is guaranteed to be writeable for any user., |
| # 22:05:05 | Juv1228 | yes, i understand this |
| # 22:05:15 | Juv1228 | im not proposing that line be changed |
| # 22:05:33 | y_morin | Juv1228: Yes, understood. Now, lets come up with a solution! ;-) |
| # 22:05:37 | Juv1228 | im proposing some sort of 'local' configuration be available to override options in a sample configuration |
| # 22:06:04 | Juv1228 | so, if an option appears in .local-config or something, it would replace the option used in the sample |
| # 22:06:15 | y_morin | Juv1228: I'm not really happy with this solution. |
| # 22:06:40 | Juv1228 | ok, what about it doesnt sound good to you? |
| # 22:07:09 | y_morin | Juv1228: would it be acceptable if saveconfig used some environment variable, and if not set, use the current defaults? |
| # 22:08:07 | Juv1228 | so if a variable is set dont run that filter line in saveSample.sh? |
| # 22:08:08 | y_morin | Juv1228: Providing an override feature is prone to widely open a door to a whole lot of compatibility issues in the config. |
| # 22:08:32 | y_morin | Juv1228: Run the line, but with the content of that variable, for example: |
| # 22:08:40 | Juv1228 | ah, ok |
| # 22:09:19 | Juv1228 | there would need to be two of said variable then, one for CT_PREFIX_DIR and one for CT_LOCAL_TARBALLS_DIR |
| # 22:09:29 | y_morin | Juv1228: to save CT_LOCAL_TARBALLS_DIR, look at ${CT_OVERRIDE_TARBALLS_DIR}, and if not set, use ${HOME}/src. |
| # 22:09:37 | y_morin | Juv1228: yep. |
| # 22:09:38 | Juv1228 | yes, i understand now |
| # 22:09:55 | y_morin | Juv1228: do you think that would be acceptable for your use-case? |
| # 22:10:26 | Juv1228 | i think so, as long as it would be possible to set those variables in the wrapper makefile we have |
| # 22:10:41 | Juv1228 | we are currently importing the ct-ng makefile script in ours |
| # 22:11:55 | y_morin | Juv1228: there is a feature in ct-ng so it behaves as a "backend" for an upper-layer build-system. Have you looked at it? |
| # 22:12:06 | y_morin | Juv1228: that's what is used in buildroot, for example. |
| # 22:12:33 | Juv1228 | yes, knew it existed (we are also looking at using buildroot) but i have not looked into it yet |
| # 22:13:32 | y_morin | Juv1228: That feature is probably badly explained in the doc, so if you need more info, just say so on the list, I'll see how to enhance the docs. |
| # 22:13:54 | Juv1228 | i think one of the things that was not liked about that solution for our team is wanting to keep the toolchain and our root filesystem separated |
| # 22:14:13 | Juv1228 | we have many users who would like to have just the toolchain and use our pre-built rootfs/kernel etc |
| # 22:14:52 | y_morin | Juv1228: OK, that makes sense. |
| # 22:15:24 | Juv1228 | thanks for the information, ill take a look into that feature and see if i can make it work for us |
| # 22:16:27 | y_morin | Juv1228: I was looking at your forbid-downloads patch: there was an explicit change to still use the mirror even if downloads were forbidden: http://crosstool-ng.org/hg/crosstool-ng/rev/d6b2354d9d17 |
| # 22:17:51 | y_morin | Juv1228: But I think your patch is not bad either. I have to think about it some more (not tonight, but tomorrow, sure). |
| # 22:18:19 | y_morin | Juv1228: And OK for your newlib patch (I'll apply tomorrow also) |
| # 22:18:23 | Juv1228 | ok, well if you want to discuss it any more you can find me here |
| # 22:18:39 | Juv1228 | i have to go now, thanks for the help |
| # 22:18:43 | y_morin | Juv1228: See ya! |
| # 22:19:25 | y_morin | Juv1228: your newlib patch is not signed-of-by. |
| # 22:40:37 | y_morin | quits : Quit: Nighty Night! |
| # 22:59:38 | smartin | quits : Quit: leaving |
| # 23:06:35 | redengin | quits : Ping timeout: 255 seconds |