# 04:42:07 |
sh4rm4 |
quits : Ping timeout: 276 seconds |
# 04:55:07 |
sh4rm4 |
joins #crosstool-ng |
# 08:49:43 |
daggs1 |
quits : Read error: Operation timed out |
# 09:05:06 |
daggs1 |
joins #crosstool-ng |
# 09:11:51 |
daggs1 |
quits : Ping timeout: 252 seconds |
# 09:25:18 |
daggs1 |
joins #crosstool-ng |
# 09:33:06 |
daggs1 |
quits : Ping timeout: 272 seconds |
# 09:45:52 |
daggs1 |
joins #crosstool-ng |
# 10:18:54 |
daggs1 |
quits : Ping timeout: 245 seconds |
# 10:32:49 |
daggs1 |
joins #crosstool-ng |
# 11:00:15 |
daggs1 |
quits : Quit: Leaving |
# 13:24:50 |
smartin |
joins #crosstool-ng |
# 17:18:08 |
daggs1 |
joins #crosstool-ng |
# 18:59:11 |
bhundven |
joins #crosstool-ng |
# 19:02:32 |
bhundven |
got a mercurial question for anyone willing to help. I have a patch for the eglibc-2.15 issue I mentioned on the mailing list. I did 'hg qnew -e eglibc_remove_test_except_builtin' then put my change in the right spot in the patches/eglibc/2_15 directory. 'hg qrefresh', and the file is not in the queue i made. Anyone know how to add a new file to a queue, or does that only work for edits? |
# 19:25:04 |
smartin |
quits |
# 19:47:49 |
bhundven |
well, anyways. I've got an e500mc 32-bit mutlilib (hard-float/soft-float) toolchain working now. |
# 20:05:14 |
smartin |
joins #crosstool-ng |
# 20:51:25 |
bhundven |
GCC 4.7.0 (changes) Status: 2012-03-02 (frozen for release). |
# 21:45:20 |
y_morin |
joins #crosstool-ng |
# 21:46:34 |
bhundven |
hey y_morin |
# 21:46:48 |
y_morin |
bhundven: hello there! :-) |
# 21:47:36 |
y_morin |
bhundven: did you run 'hg add file-to-add' before qrefresh? |
# 21:47:45 |
bhundven |
oh |
# 21:47:47 |
bhundven |
hehe |
# 21:47:51 |
bhundven |
no |
# 21:47:57 |
bhundven |
thanks |
# 21:48:08 |
y_morin |
bhundven: 'hg addremove' does all the 'adds' and 'removes' it can find, too. |
# 21:48:21 |
bhundven |
ok. good tip |
# 21:49:48 |
bhundven |
on x86_64, building multlib for x86_64/x86_32, in headers & start files for 32: |
# 21:49:51 |
bhundven |
[CFG ] checking for x86-64 TLS support... no |
# 21:49:54 |
bhundven |
[ERROR] configure: error: the assembler must support TLS |
# 21:50:23 |
y_morin |
bhundven: yes, multilib failed on me, too. I did not have the incentive to investigate yet... |
# 21:51:29 |
bhundven |
but, I did get a 32-bit multilib e500mc that outputs both hard and soft float. works great. |
# 21:51:54 |
y_morin |
bhundven: I meant, multilib for x86 target. |
# 21:51:57 |
bhundven |
right |
# 21:52:28 |
bhundven |
I'm trying again with the binutils-multiarch package installed |
# 21:53:20 |
y_morin |
bhundven: last I tried, I had to install the lib32 packages on my x86_64 host, otherwise, it can not find (something...). |
# 21:54:08 |
y_morin |
It should not be required to install such host packages to be able to build a multilib toolchain. gcc should be able to build its own internal xgcc properly... |
# 21:54:11 |
y_morin |
Sigh... |
# 21:54:49 |
bhundven |
yea, I keep getting told about this perfect world... can't find it :D |
# 21:55:09 |
y_morin |
smiles... :-) |
# 22:07:43 |
bhundven |
configure:24: x86_64-unknown-linux-gnu-gcc -m32 -c -U_FORTIFY_SOURCE -O2 conftest.s 1>&5 |
# 22:07:46 |
bhundven |
conftest.s: Assembler messages: |
# 22:07:49 |
bhundven |
conftest.s:8: Error: bad register name `%rip)' |
# 22:07:55 |
bhundven |
eh, ic now |
# 22:09:06 |
bhundven |
eglibc issue |
# 22:10:46 |
y_morin |
bhundven: if you do not know which to blame, start with gcc. If not gcc's fault, it's glibc's. If still not glibc's, it's binutils'. And so on.. until you bash me! ;-) |
# 22:11:26 |
bhundven |
it's eglibc's fault. It's using 64-bit assmebly test to check for tls when building the 32-bit multilib part |
# 22:11:52 |
bhundven |
well |
# 22:11:56 |
bhundven |
(e)glibc |
# 22:52:00 |
smartin |
quits |
# 22:58:44 |
bhundven |
http://cross-lfs.org/view/svn/x86_64/cross-tools/variables.html |
# 22:58:46 |
bhundven |
eh |
# 22:59:02 |
bhundven |
lfs uses a different --target for 32-bit in multilib |
# 22:59:23 |
bhundven |
and that would make sense |
# 23:04:05 |
y_morin |
bhundven: does binutils 2.22 really require cloog, now ? |
# 23:04:14 |
y_morin |
(and ppl?) |
# 23:04:22 |
bhundven |
idk, it still checks for them |
# 23:06:15 |
bhundven |
y_morin: so that was the problem. the --target needs to be i686-*-linux-* for the 32-bit part of the multilib components |
# 23:06:27 |
bhundven |
or it runs the wrong autoconf tests |
# 23:07:23 |
y_morin |
bhundven: OK, but that's just stupid. IIRC, there is a switch to gcc's or glibc's ./configure that specifies the 32-bit tuple... Lemme check... |
# 23:08:51 |
y_morin |
bhundven: forget it, I was wrong. I was thinking about the --with-{arch,tune,cpu}-{32,64} flags to gcc's ./configure. Never mind... |
# 23:09:44 |
y_morin |
bhundven: so, in case the multilib is not the same bitness as the default, we have to tweak the tuple, right? |
# 23:10:02 |
bhundven |
right |
# 23:10:10 |
bhundven |
I'm working on a patch for x86 |
# 23:10:24 |
bhundven |
I'll look at ppc later |
# 23:11:06 |
y_morin |
bhundven: OK, thanks. I think the way to go would be to have each arch set both tuple, the default one, and the alternate multilib one if needed. |
# 23:11:18 |
bhundven |
yes, if CT_MULTILIB |
# 23:11:30 |
y_morin |
then components such as glibc could choose which to use (depending on... carefully crafted tests, I guess...) |
# 23:12:17 |
bhundven |
hmm, this might be more tricky then I initially thought |
# 23:12:24 |
bhundven |
hehe |
# 23:12:44 |
y_morin |
yes, it's not gonna be easy... |
# 23:13:32 |
bhundven |
for instance. on e500mc/e500v2, if you build multilib, you get soft or hard float. if you build e500mc64, you get 32 and 64, soft and hard float. |
# 23:13:43 |
y_morin |
bhundven: BTW, do you know anything about how gcc behaves for ARM+EABI? I tried multilib on ARM EABI, but ./configure decides there was no multilib available.... |
# 23:13:59 |
bhundven |
hmm |
# 23:14:05 |
bhundven |
idk, I'd have to try it |
# 23:14:26 |
y_morin |
bhundven: I think the test should check if -m{32,64} is set, and if it is and does not match the default bitness, switch to using the alternate tuple if set. |
# 23:14:40 |
bhundven |
yea |
# 23:14:46 |
y_morin |
bhundven: forget about ARM if you don;t know, I was just asking just in case... |
# 23:15:48 |
y_morin |
(OK, just built a new ARM toolchain with latest components: gcc-4.6.2-linaro uclibc-0.9.33, binutils-2.22, kernel headers 3.2.6. Woohoo! :-) ) |
# 23:17:37 |
bhundven |
hehe, nice |
# 23:18:11 |
bhundven |
got gcc-4.6.3, eglibc-2.15, binutils-2.22, and linux-3.2.8 on my e500mc and x86_64 builds |
# 23:18:12 |
y_morin |
With NPTL ! :-) |
# 23:18:25 |
bhundven |
oh, yea, uclibc fixed that, huh. |
# 23:18:26 |
y_morin |
bhundven: Nice! :-) |
# 23:18:52 |
bhundven |
e500mc was much easier then e500v2 |
# 23:19:07 |
bhundven |
still has the -Os issue though |
# 23:26:22 |
bhundven |
hmm |
# 23:26:56 |
bhundven |
another problem is x86_64-multilib vs. i386-multilib |
# 23:28:01 |
bhundven |
x86_64 being, default to x86_64, but able to output 32-bit with -m32, and i386-multilib being default 32-bit, but able to output x86_64 -m64 binaries |
# 23:28:49 |
y_morin |
bhundven: yes, the test should be smthg like: |
# 23:29:11 |
bhundven |
the variable ${multilib} will contain m32 |
# 23:29:19 |
bhundven |
on x86_64 multilib |
# 23:29:21 |
y_morin |
- if (multilib args contain -m32) and (arch is 64), then use alternate tuple |
# 23:29:27 |
bhundven |
yup |
# 23:29:32 |
bhundven |
jinx |
# 23:29:46 |
y_morin |
- and conversely for 64/32... |
# 23:29:56 |
bhundven |
yup |
# 23:37:13 |
y_morin |
bhundven: I think we could also do something like that: http://code.bulix.org/xpnt1b-81169 |
# 23:37:46 |
y_morin |
bhundven: for those arch that accept the --with-{arch,tune,cpu}-{32,64} configure flags of gcc. |
# 23:38:03 |
y_morin |
It's just a brain-dump, of course! :-] |
# 23:38:20 |
bhundven |
well, we get the multilibs variable when we get done with the core-cc-1 |
# 23:38:35 |
bhundven |
just before we start on headers & start files |
# 23:39:09 |
bhundven |
probably better to get the alternate from gcc then some configuration that someone can screw up |
# 23:39:12 |
y_morin |
bhundven: nope, I was refering to the default -mcpu -mtune and -march flags |
# 23:39:22 |
bhundven |
oh |
# 23:39:36 |
bhundven |
looks again |
# 23:39:53 |
y_morin |
bhundven: http://gcc.gnu.org/install/configure.html <- look for --with-arch-32 (and the likes) |
# 23:39:59 |
bhundven |
yea |
# 23:40:39 |
y_morin |
runs one last build before heading to bed... |
# 23:40:51 |
bhundven |
heh |
# 23:41:59 |
y_morin |
is trying to start working on a freedombox-like device... |
# 23:42:48 |
bhundven |
hmm |
# 23:42:54 |
bhundven |
never heard of that before |
# 23:43:00 |
bhundven |
just found the website |
# 23:43:48 |
y_morin |
bhundven: it's steered by Eben Moglen, of SFLC (https://www.softwarefreedom.org/) |
# 23:47:01 |
y_morin |
..../arm-unknown-linux-uclibcgnueabi/bin/ld: BFD (crosstool-NG hg+default-4fcedd2c14b2) 2.22 assertion fail ..../binutils-2.22/bfd/elf32-arm.c:12049 |
# 23:47:11 |
y_morin |
Not too good... :-( |
# 23:47:29 |
y_morin |
OK, time for some rest. |
# 23:47:32 |
y_morin |
See ya later! |
# 23:47:34 |
y_morin |
quits : Quit: Quitting... |
# 23:48:26 |
bhundven |
g'night |