ibotlog2html for #crosstool-ng

<< Previous 2014-03-19 Next >>

# 01:23:34 djerome joins #crosstool-ng
# 03:37:05 djerome quits : Remote host closed the connection
# 03:53:38 alan_o quits : Remote host closed the connection
# 06:11:38 sh4rm4 quits : Ping timeout: 252 seconds
# 06:20:19 sh4rm4 joins #crosstool-ng
# 08:11:38 aalv joins #crosstool-ng
# 09:32:56 sh4rm4 quits : Ping timeout: 252 seconds
# 10:00:19 sh4rm4 joins #crosstool-ng
# 10:20:14 sh4rm4 quits : Ping timeout: 252 seconds
# 12:53:46 sh4rm4 joins #crosstool-ng
# 13:09:05 sh4rm4 quits : Ping timeout: 252 seconds
# 13:23:07 alan_o joins #crosstool-ng
# 13:31:48 sh4rm4 joins #crosstool-ng
# 14:18:23 sh4rm4 quits : Ping timeout: 252 seconds
# 14:55:49 sh4rm4 joins #crosstool-ng
# 15:03:39 sh4rm4 quits : Remote host closed the connection
# 15:06:16 sh4rm4 joins #crosstool-ng
# 16:11:13 aalv quits : Remote host closed the connection
# 18:29:47 y_morin joins #crosstool-ng
# 18:30:06 xrl_____ quits : Ping timeout: 264 seconds
# 18:32:37 xrl_____ joins #crosstool-ng
# 18:41:55 tlwoerner quits : Quit: Leaving
# 18:45:27 tlwoerner joins #crosstool-ng
# 19:04:30 smartin_ joins #crosstool-ng
# 19:04:30 tlwoerner quits : Quit: Leaving
# 19:05:05 tlwoerner joins #crosstool-ng
# 19:45:04 alan_o Does anyone understand this problem: http://stackoverflow.com/questions/14207189/crosstools-ng-cant-find-pthread-so
# 19:45:17 alan_o Everything I find says "change in the .so." Seems wrong.
# 19:48:03 bhundven alan_o: what version of crosstool-ng are you using?
# 19:48:18 dalias the answer looks correct to me
# 19:48:18 bhundven are you using the 1.19.0 release or tip from hg?
# 19:48:25 dalias having hard-coded paths in that file does not make sense
# 19:48:39 bhundven dalias: right
# 19:49:01 bhundven how did the hardcoded paths get there?
# 19:49:10 alan_o I'm actually using one from codesourcery, but since the SO post mentioned ct-ng I thought you might have information on the general issue.
# 19:49:23 bhundven oh
# 19:49:24 alan_o Sorry to be "that guy" :(
# 19:49:24 bhundven nm
# 19:49:26 dalias :)
# 19:49:37 alan_o So you think hardcoded paths should not be there?
# 19:49:50 alan_o let me check my ct-ng toolchain
# 19:50:01 bhundven did the toolchain come that way?
# 19:50:17 alan_o yes. It buildroot downloaded it
# 19:50:47 bhundven I'm still drinking first cup of coffee
# 19:51:28 alan_o my ct-ng toolchain has the same
# 19:51:35 bhundven I'm kind of like starting up a diesel engine, the glow plugs are still warming up...
# 19:51:54 dalias :)
# 19:52:02 alan_o but the difference is, my ct-ng toolchain is for arm, so maybe something detected the arch difference and didn't try to use it.
# 19:53:08 bhundven it's gcc's job to figure out the paths for files, the linker script should just be saying the names of the libraries to link in.
# 19:54:52 alan_o hmm
# 19:57:07 bhundven (technically, collect2)
# 19:57:37 bhundven but you don't invoke that directly, gcc handles that through the driver interface (specs)
# 20:00:37 alan_o hmm, after modifying the .so file, I get similar with libc
# 20:00:42 alan_o http://dpaste.com/1746356/
# 20:01:01 alan_o ^ trying to cross-build boost (which is enough of a nightmare by itself)
# 20:01:36 bhundven hrm, maybe I'm confused.
# 20:01:55 bhundven that is without the paths?
# 20:02:21 alan_o I took the hard-coded paths out of libpthread.so but now I'm getting the same error on libc
# 20:02:39 alan_o and yes, that paste is without the libpthread.so hard-coded paths
# 20:04:45 alan_o does the compiler somehow not know it's cross-compiling?
# 20:05:34 bhundven no
# 20:05:48 bhundven what is your host platform/os?
# 20:06:29 bhundven your ct-ng toolchain, what version are you using?
# 20:06:39 bhundven version of ct-ng, that is.
# 20:06:54 smartin_ quits : Write error: Broken pipe
# 20:07:10 bhundven I know there are fixes for armeabihf in hg not in the 1.19.0 release
# 20:08:07 alan_o Well the paste is not from the ct-ng one. My ct-ng one is for arm. This is a host of x86_64 building for i686
# 20:08:43 alan_o ct-ng one is pretty old. Could build up a new one for i686.
# 20:09:24 bhundven ok, I don't mess with build/host x86_64 target i686 much.
# 20:10:08 bhundven brb... need more caffeine.
# 20:10:10 alan_o yeah, it's "kind-of cross." The issue may be related to that.
# 20:12:15 smartin_ joins #crosstool-ng
# 20:28:19 alan_o In my test program, it looks like the problem starts when I set the library path to point to the buildroot-built library directory. I bet that directory has stuff that was built with the native compiler (because I was screwing with it).
# 20:32:42 bhundven problem: screwing with it :D
# 20:36:30 alan_o could be.... doing a clean on buildroot now and making sure it's building with the right tools. It'd be nice to be able to disable all your local (native) build tools temporarily (headers, libs, compilers, etc).
# 20:46:36 bhundven oh
# 20:47:34 bhundven coffee helped
# 20:47:40 bhundven now I see the problem you posted
# 20:48:09 bhundven /lib/arm... is wrong
# 20:48:15 bhundven but /lib/... is right
# 20:48:23 bhundven the paths are relative to the sysroot
# 20:48:57 bhundven so, you need the paths, but not the /lib/arm-linux-gnueabihf... and /usr/lib/arm-linux-gnueabihf
# 20:49:11 bhundven >.< #awakenow
# 20:51:38 alan_o ok, interesting
# 21:04:23 bhundven https://sourceware.org/binutils/docs-2.24/ld/File-Commands.html#File-Commands
# 21:04:32 bhundven See definitions for INPUT and GROUP
# 21:04:48 bhundven "In case a sysroot prefix is configured, and the filename starts with the `/' character, and the script being processed was located inside the sysroot prefix, the filename will be looked for in the sysroot prefix. Otherwise, the linker will try to open the file in the current directory. If it is not found, the linker will search through the archive library
# 21:04:48 bhundven search path. See the description of `-L' in Command Line Options."
# 21:12:55 bhundven updated on stackoverflow
# 21:28:09 alan_o hmm. thanks
# 21:28:17 alan_o So maybe it's confused about where its sysroot is.
# 21:29:13 bhundven you can find out with gcc -print-sysroot
# 21:32:10 alan_o yeah, it points into the toolchain. If I give it --sysroot=/my/buildroot/stuff/.../sysroot/ then it works.
# 21:35:06 bhundven strangeness, maybe old ct-ng/buildroot?
# 21:36:26 bhundven try ct-ng from hg: hg clone http://crosstool-ng.org/hg/crosstool-ng
# 21:36:50 bhundven or you can get the bz2 of tip: http://crosstool-ng.org/hg/crosstool-ng/archive/tip.tar.bz2
# 21:42:13 y_morin alan_o: So, you're not using a crostool-NG toolchain?
# 21:43:24 y_morin alan_o: We can try to help on other side issues, but we are mostly focused on crosstool-NG.
# 21:43:25 alan_o y_morin: not on this particular problem. It's x86 so I let buildroot grab one for me. My ct-ng's are on ARM.
# 21:43:47 y_morin alan_o: So, if it is a buildroot isue, you should ask on #buildroot.
# 21:44:41 alan_o y_morin: absolutely. I didn't intend on getting this much support actually. I thought I could get a quick answer on whether the stackoverflow answer (which cited ct-ng) was correct/necessary, and it turns out it wasn't.
# 21:45:51 alan_o y_morin: the toolchain in this case Buildroot downloaded from from CodeSourcery.
# 21:46:31 y_morin alan_o: So, it is a problem with a codesourcery toolchain. First, I fint it odd there's a problem with these toolchains: they get pretty much tested in Buildroot.
# 21:46:47 alan_o I'm not sure there's a problem.
# 21:47:03 y_morin alan_o: Second, if (and that's a big 'if') there is a problem with that toolchain, you should bug CodeSourcery.
# 21:47:23 alan_o Indeed.
# 21:48:01 y_morin alan_o: Sorry, I'm lost: why do you ask about http://stackoverflow.com/questions/14207189/crosstools-ng-cant-find-pthread-so if that's not a problem for you?
# 21:48:21 alan_o y_morin: I'm having that same problem.
# 21:48:54 alan_o Where it's telling me it can't find /lib/libpthread.so, which lead to the discussion about whether that was an absolute path or not.
# 21:49:12 y_morin alan_o: OK. Then, maybe bug #buildroot with a comprehensive problem report (eg. can't build package FOO with toolchain BLA).
# 21:49:17 bhundven sounds to me like an environment/setup issue, not related to ct-ng, buildroot, codesourcery, or boost. ;)
# 21:49:36 alan_o ^^ yes, I think it's that
# 21:50:06 y_morin bhundven: Maybe. But it is really strange. And anyway, the best place to ask is not here, I'm afraid. :-(
# 21:50:17 bhundven y_morin: agreed
# 21:52:00 y_morin alan_o: And by the way, the content of libpthread.so is correct.
# 21:52:03 alan_o Yeah, now that I know more about what it's supposed to do. I think the next step is to ask over in #buildroot whether I should have to use --sysroot.
# 21:52:18 y_morin alan_o: Switching over there, then.
# 21:53:16 bhundven alan_o: should also un-site crosstool-ng in the question
# 21:55:06 bhundven *cite
# 21:56:32 y_morin bhundven: Turns out, alan_o's post on #buildroot is very explicit about the issue!
# 21:56:44 y_morin bhundven: Which is indeed a purely Buildroot-related issue.
# 21:56:56 bhundven y_morin: well, there ya go.
# 21:56:58 bhundven :D
# 21:57:30 alan_o y_morin: well yes, but now I know more than I did when I started here, or well, I know more about what's relevant.
# 21:57:57 y_morin alan_o: Yep, which is OK. We all learn! ;-)
# 21:57:58 alan_o I often find that coming up with the right question is one of the harder parts
# 21:58:01 alan_o maybe that's just me :)
# 21:58:24 y_morin alan_o: No, you;re right: asking the right question is difficult.
# 21:58:47 y_morin alan_o: But trying to give random giuesses as to what the solution might be does not help.
# 21:59:12 y_morin alan_o: You should always just say: here's what I've done, here's what I expected, here's what I got.
# 21:59:30 y_morin alan_o: Then: either you expected wrong and the result is correct, and you get to learn why.
# 21:59:53 y_morin alan_o: Or the result is wrong and you expected correct, and we get to know the exact conditions so we have a starting point.
# 22:02:54 alan_o In hindsight it's all clear to me what I should have done, as usual :)
# 22:03:11 alan_o Thanks guys for your help. It is much appreciated
# 22:03:34 bhundven alan_o: no problem!
# 22:22:27 smartin_ quits : Quit: good night
# 22:43:58 bhundven learns about parallel processing in bash with xargs :D XP +2000
# 22:45:05 bhundven now the output of this script I'm hacking is ugly as hell :p
# 22:46:39 y_morin bhundven: achievement unlocked! :-)
# 22:46:44 bhundven seriously
# 22:46:54 y_morin bhundven: And you can use co-processes in bash 4.2+
# 22:47:06 bhundven yea, I wanted backwards compatibility
# 22:47:09 y_morin bhundven: co-processes == multi-threads.
# 22:47:15 y_morin bhundven: Yep.
# 22:48:48 bhundven export -f mycustomfetch; find . -name '*\.git' -print0 | xargs -0 -i --max-args=1 --max-procs= bash -c 'mycustomfetch $@' _ {}
# 22:50:01 y_morin bhundven: I have 'update.me' that does exactly that! :-)
# 22:50:22 bhundven I keep a /mirrors directory
# 22:50:28 y_morin (ugly shell script that does git pull, hg pull --update, svn up, cvs update, and so on...)
# 22:50:36 bhundven full of git clone --mirror directories
# 22:50:39 y_morin bhundven: I have ~/cache for that! :-)
# 22:50:43 bhundven :D
# 22:50:48 bhundven great minds think alike
# 22:50:52 y_morin +!
# 22:50:55 y_morin +1
# 22:51:30 y_morin bhundven: Plus a 'git gc-all ~/cache' from time to time, to regain a bit of place...
# 22:54:46 bhundven makes a note about gc-all
# 22:55:11 y_morin bhundven: I can share it if you want.
# 22:56:15 bhundven I think in mycustomfetch, I'll just add: git gc --auto & so that it just does it in the background if it is needed.
# 22:57:49 bhundven can you do: || & to do this or that in the background?
# 22:58:20 bhundven need to error out if gc fails
# 22:58:53 y_morin bhundven: In case it can help: http://code.bulix.org/101mf9-85875
# 22:59:12 y_morin bhundven: ( foo || bar ) &
# 22:59:31 bhundven y_morin: yup! thanks! subshell
# 22:59:57 y_morin bhundven: In my case, since update.me and git gc-all can run concurrently, I need to lock the repositories so they do not conflict.
# 23:00:58 y_morin Not to say my solution is better: it's been evolving organically over many years, and it is good enough so that I do not bother hacking more than fixing the odd bugs...
# 23:03:02 bhundven it's much more eloquent then my cruft :D Thanks y_morin!
# 23:03:17 y_morin bhundven: Want my update.me as well?
# 23:05:02 y_morin bhundven: http://code.bulix.org/ozv7ln-85876
# 23:06:10 bhundven do_it!
# 23:06:21 y_morin Yep! :-)
# 23:07:07 y_morin bhundven: Locking mechanisms are different (written at different point in time), but they are compatible.
# 23:12:36 bhundven ok, I'm out for a while. gotta do other stuff. Thanks for the new toys, y_morin!
# 23:36:21 y_morin quits : Quit: Nighty Night!

Generated by ibotlog2html by Yann E. MORIN