| # 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! |