ibotlog2html for #crosstool-ng

<< Previous 2012-03-02 Next >>

# 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

Generated by ibotlog2html by Yann E. MORIN