| # 01:56:38 | al` | quits : *.net *.split |
| # 01:56:56 | al` | joins #crosstool-ng |
| # 02:05:18 | codyps | quits : Ping timeout: 255 seconds |
| # 05:24:58 | alan_o | quits : Quit: Leaving |
| # 07:20:25 | smartin | joins #crosstool-ng |
| # 09:36:18 | sh4rm4 | quits : Remote host closed the connection |
| # 09:37:04 | sh4rm4 | joins #crosstool-ng |
| # 10:59:13 | CatKiller | joins #crosstool-ng |
| # 10:59:18 | CatKiller | Hi there! |
| # 10:59:36 | CatKiller | I have a small question but I'm unsure if this is the best place to ask |
| # 11:00:48 | CatKiller | I have a built toolchain (made with crosstool), It is using a set of linux headers and libraries taken from the latest kernel version at the time of building that toolchain (2.6.15). |
| # 11:01:22 | CatKiller | I'm building a linux distro using that toolchain, including the kernel |
| # 11:01:35 | CatKiller | the kernel version we're building is 3.4, while using that dating toolchain |
| # 11:02:44 | CatKiller | Would building a 3.4 kernel with a toolchain that relies on libraries from kernel 2.6.15 be a problem, or would the cross-compiling gcc use the "right" libraries directly from the 3.4 source we're compiling? |
| # 12:09:50 | smartin | CatKiller: building the kernel (and only the kernel) should be ok |
| # 12:10:41 | smartin | because the kernel does not rely on any other 3rd party stuff, just itself |
| # 12:16:06 | smartin | however, weirdnesses can occur building the libc or other software, or at runtime... |
| # 12:47:21 | CatKiller | smartin: Thanks a lot, I understand better now! |
| # 12:48:11 | CatKiller | smartin: Would it be recommended to have built my userland tools using the linux headers of the target linux kernel? |
| # 12:53:30 | smartin | humm... here is the point it's not easy to answer, afaik, kernel maintain API/ABI backward compat |
| # 12:54:56 | smartin | so, if you only use the API of the oldest version of the header (in your case, those from the toolchain), i think it should works |
| # 13:00:55 | CatKiller | smartin: Sounds good |
| # 13:00:59 | CatKiller | it does indeed work |
| # 13:01:17 | CatKiller | I was more wondering about what was "The right thing to do" |
| # 13:01:20 | CatKiller | ;) |
| # 13:02:06 | y_morin | joins #crosstool-ng |
| # 13:26:56 | smartin | y_morin: hi |
| # 13:28:12 | smartin | back from lsm |
| # 13:29:16 | sh4rm4 | quits : Remote host closed the connection |
| # 13:29:42 | smartin | some weeks ago i asked about static toolchain on mac |
| # 13:31:01 | smartin | recently at work, i did some self-contained toolchain, |
| # 13:32:49 | smartin | but to do that I had to copy libgcc_s and libstdc++ from the system to the toolchain and tweak rpath of all binaries linking against one or the other of these 2 libs |
| # 13:43:25 | y_morin | smartin: hello! Back too! :-) |
| # 13:43:46 | y_morin | smartin: dirty trick... :-( |
| # 13:47:43 | smartin | at least it does the job |
| # 13:48:25 | smartin | what about the redistribution of such a toolchain? |
| # 13:49:41 | smartin | those 2 libs are provided by gcc 4.5 installed through port. |
| # 13:53:29 | y_morin | smartin: IANAL, but I believe you should also provide the means to rebuild those libs, too. |
| # 13:53:42 | y_morin | smartin: you were at LSM too? |
| # 14:01:38 | smartin | y_morin: no |
| # 14:01:55 | y_morin | smartin: Ah, I misread your msg... |
| # 14:36:45 | smartin | y_morin: migrating kconfig-frontend to git is still your todo list? |
| # 14:37:24 | y_morin | smartin: yes, it is. But rather low on the lisT! I need to set up a git server so I can experiment first. |
| # 14:37:33 | smartin | what about crosstool-ng? |
| # 14:37:38 | y_morin | smartin: nope. |
| # 14:37:47 | smartin | a bit trolling ;) |
| # 14:38:12 | smartin | I'm so dummy and lost using hg... |
| # 14:38:22 | y_morin | smartin: The reason I will migrate kconfig-frontends is to use the same VCS as the kernel. |
| # 14:38:35 | y_morin | While crosstool-NG is a totally separate project. |
| # 14:39:02 | y_morin | feeds the troll... ;-) |
| # 16:30:16 | codyps | joins #crosstool-ng |
| # 16:47:01 | linuxjacques | hi y_morin I tried out the patches on the list for gcc 4.7.1 and eglibc 2.16 |
| # 16:47:30 | linuxjacques | gcc 4.7.1 seems fine |
| # 16:48:26 | linuxjacques | eglibc 2.16 seems to have a problem specific to e500 SPE - they moved some files around and (as usual) forgot the SPE case |
| # 17:00:47 | smartin | quits : Quit: leaving |
| # 17:07:16 | alan_o | joins #crosstool-ng |
| # 18:06:39 | smartin | joins #crosstool-ng |
| # 21:22:11 | sh4rm4 | joins #crosstool-ng |
| # 21:23:41 | y_morin | quits : Quit: G'd night! (the first in a week where I will have a decent sleep!) |
| # 22:53:32 | smartin | quits : Quit: leaving |
| # 23:55:59 | codyps | quits : Ping timeout: 246 seconds |