| # 00:18:00 |
alan_o |
joins #crosstool-ng |
| # 01:05:20 |
dprice |
joins #crosstool-ng |
| # 01:07:23 |
dprice |
quits : Client Quit |
| # 01:08:56 |
mingwandroid1 |
quits : Quit: Leaving. |
| # 01:09:12 |
mingwandroid |
joins #crosstool-ng |
| # 01:09:29 |
dprice |
joins #crosstool-ng |
| # 01:09:33 |
devcoder |
joins #crosstool-ng |
| # 01:13:14 |
mingwandroid |
quits : Ping timeout: 240 seconds |
| # 01:13:36 |
dprice |
quits : Ping timeout: 240 seconds |
| # 01:30:03 |
dprice |
joins #crosstool-ng |
| # 02:25:58 |
devcoder |
quits : Quit: devcoder |
| # 02:46:04 |
thewonderidiot |
quits : Quit: leaving |
| # 03:28:13 |
dprice |
quits : Quit: Leaving. |
| # 03:29:14 |
alan_o |
quits : Quit: Leaving |
| # 03:29:32 |
papalazarou |
parts #crosstool-ng |
| # 06:42:35 |
ssspiff |
quits : Quit: Leaving |
| # 07:25:56 |
diorcety |
quits : Read error: Connection reset by peer |
| # 07:48:25 |
mingwandroid |
joins #crosstool-ng |
| # 08:15:03 |
diorcety |
joins #crosstool-ng |
| # 08:35:22 |
mingwandroid |
quits : Quit: Leaving. |
| # 08:38:10 |
Net147 |
joins #crosstool-ng |
| # 08:56:00 |
Net147 |
quits : Quit: HydraIRC -> http://www.hydrairc.com <- Organize your IRC |
| # 08:56:15 |
smartin |
joins #crosstool-ng |
| # 10:20:03 |
ssspiff |
joins #crosstool-ng |
| # 10:20:43 |
sspiff |
quits : Ping timeout: 260 seconds |
| # 11:10:12 |
imMute |
quits : Ping timeout: 248 seconds |
| # 11:17:22 |
imMute |
joins #crosstool-ng |
| # 13:31:00 |
sfan5|OFF |
is now known as: sfan5 |
| # 14:33:18 |
ssspiff |
quits : Remote host closed the connection |
| # 14:49:00 |
alan_o |
joins #crosstool-ng |
| # 15:20:53 |
alan_o |
quits : Ping timeout: 252 seconds |
| # 15:29:22 |
diorcety |
quits : Quit: Leaving. |
| # 15:33:01 |
alan_o |
joins #crosstool-ng |
| # 15:33:21 |
boucman_work |
quits : Ping timeout: 252 seconds |
| # 15:41:29 |
boucman_work |
joins #crosstool-ng |
| # 16:37:24 |
thewonderidiot |
joins #crosstool-ng |
| # 17:43:51 |
y_morin |
joins #crosstool-ng |
| # 17:47:54 |
thewonderidiot |
heya y_morin |
| # 17:48:26 |
thewonderidiot |
just wanted to let you know that my cross compiler built fine, and works! |
| # 17:48:30 |
thewonderidiot |
thanks a million for the help |
| # 17:49:01 |
y_morin |
thewonderidiot: Nice to read! Cheers! |
| # 18:14:43 |
smartin |
quits |
| # 18:31:14 |
dprice |
joins #crosstool-ng |
| # 18:31:25 |
dprice |
quits : Read error: Connection reset by peer |
| # 18:31:39 |
dprice |
joins #crosstool-ng |
| # 19:06:04 |
diorcety |
joins #crosstool-ng |
| # 19:26:48 |
diorcety |
y_morin: thanks |
| # 19:28:58 |
alan_o |
quits : Ping timeout: 246 seconds |
| # 19:45:52 |
y_morin |
diorcety: BTW, do not use parenthesis () for your mail, use <>. |
| # 19:46:06 |
y_morin |
diorcety: eg. Jhon DOE |
| # 19:46:22 |
y_morin |
diorcety: not: John DOE (john.doe@somewhere.net) |
| # 19:46:59 |
y_morin |
diorcety: that last one is not valid as per FRC2822 ( http://www.faqs.org/rfcs/rfc2822.html ) |
| # 19:47:10 |
y_morin |
*RFC, not FRC. |
| # 20:05:26 |
diorcety |
quits : Ping timeout: 245 seconds |
| # 20:35:56 |
sfan5 |
is now known as: sfan5|OFF |
| # 20:36:00 |
alan_o |
joins #crosstool-ng |
| # 21:00:18 |
diorcety |
joins #crosstool-ng |
| # 21:03:12 |
diorcety |
y_morin: ok |
| # 21:04:48 |
sfan5|OFF |
is now known as: sfan5 |
| # 21:08:47 |
mingwandroid |
joins #crosstool-ng |
| # 21:10:59 |
y_morin |
diorcety: no need to resubmit, I'll fix the other patch locally before committing. |
| # 21:28:29 |
mingwandroid |
y_morin: hi. |
| # 21:31:22 |
y_morin |
mingwandroid: hello! |
| # 21:32:00 |
y_morin |
is trying to debug an issue in pwclient, the patchwork xmlrpc CLI client. |
| # 21:33:57 |
mingwandroid |
whoosh! that's the sound of that going over my head ;-) |
| # 21:34:19 |
mingwandroid |
so wanted to ask about cctools / ld64 a bit... |
| # 21:35:07 |
mingwandroid |
we're all in agreement that the patch to add autotools to cctools is unfortunately large. |
| # 21:35:42 |
mingwandroid |
as I've got it in toolchain4, I merge ld64 in with cctools so that both projects share the same autotools source. |
| # 21:36:57 |
y_morin |
mingwandroid: in crosstool-NG, we only use upstream to get the components. |
| # 21:37:50 |
mingwandroid |
y_morin: ok.. |
| # 21:37:54 |
y_morin |
mingwandroid: that means the cctools build script will have to download from opensource.apple.com, not from some /random/ other location. |
| # 21:38:06 |
mingwandroid |
oh yeah, that's 100% a given. |
| # 21:38:11 |
mingwandroid |
but can I do: |
| # 21:39:02 |
mingwandroid |
download("os.apple.com/cctools"); download("os.apple.com/ld64"); unpack("cctools","cctools_and_ld64"); unpack("ld64","cctools_and_ld64"); patch("cctools_and_ld64"); |
| # 21:40:09 |
y_morin |
mingwandroid: here's what I'd suggest: http://code.bulix.org/vfarfv-82476 |
| # 21:40:16 |
sfan5 |
is now known as: sfan5|OFF |
| # 21:40:21 |
y_morin |
mingwandroid: yes, that's the idea! ;-) |
| # 21:40:35 |
mingwandroid |
ok yes, great. |
| # 21:40:52 |
y_morin |
mingwandroid: that's almost-pseudo code |
| # 21:41:23 |
mingwandroid |
you mean I can't use it exactly as-is? |
| # 21:41:43 |
mingwandroid |
;-) |
| # 21:42:19 |
y_morin |
mingwandroid: no, that was only to show what you could do. It's equivalent to your pseudo-code. |
| # 21:42:35 |
y_morin |
mingwandroid: I mean, it was only to show the sequence. |
| # 21:42:50 |
smartin |
joins #crosstool-ng |
| # 21:43:16 |
mingwandroid |
I know, I was just jesting. |
| # 21:43:20 |
y_morin |
;-) |
| # 21:43:50 |
mingwandroid |
actually, there was another, general thing I wanted to ask about with crosstool-ng. |
| # 21:44:44 |
mingwandroid |
from my perspective, as a long time toolchain releasing type person.. there's generally 2 modes of toolchain building that happens: |
| # 21:45:15 |
mingwandroid |
1. Build to run on the build machine, using the shared libraries, compilers and general setup of that machine. |
| # 21:46:02 |
mingwandroid |
2. Build to run on as many machines of the same OS as possible, so e.g. keeping stuff static as much as possible, using an older sysroot. |
| # 21:46:33 |
mingwandroid |
I guess from the openSSL discussions that you see crosstool-ng as firmly in camp 1, would that be a correct characterisation? |
| # 21:47:51 |
y_morin |
mingwandroid: (2) contains two orthogonal issues: a) running on as many machines as possible, and b) using an old sysroot |
| # 21:48:14 |
y_morin |
mingwandroid: Currently, with crosstool-NG, it is possible to do 1) and 2.a) |
| # 21:48:24 |
y_morin |
mingwandroid: crosstool-NG does not support 2.b) |
| # 21:49:42 |
y_morin |
mingwandroid: For OpenSSL and 2.a), we can require the user to install static version of openSSL on his/her machine, the same we require a static libc. |
| # 21:50:43 |
y_morin |
mingwandroid: My opinion about OpenSSL is that it is available on virtually all distributions, whereas the other complibs are/were not. |
| # 21:50:50 |
mingwandroid |
y_morin: well, when I say an old sysroot as a part 2, I say it in as much as e.g. Windows and Linux make strong application backward compatability guarantees. |
| # 21:51:31 |
y_morin |
mingwandroid: I'm afraid you and I do not have the same understanding of the 'sysroot'. |
| # 21:51:32 |
mingwandroid |
y_morin: ok, fair enough. the other libs are small enough as to not be much of an issue at all you know... e.g. libprunetrie is AFAIR, one .cpp file and one .h file. |
| # 21:52:03 |
y_morin |
mingwandroid: AFAICS, libprunetrie *is* part of cctools. |
| # 21:52:14 |
y_morin |
(Or am I mislead?) |
| # 21:53:05 |
y_morin |
mingwandroid: OK, let's finish about sysroot for now. |
| # 21:53:42 |
y_morin |
mingwandroid: for me, the sysroot is that part of the toolchain that (basically) contains the target headers and libs. Right? |
| # 21:53:57 |
mingwandroid |
actually it's part of ld64, but it requires some bits from another apple project to compile (dyld-195.5) |
| # 21:54:31 |
mingwandroid |
y_morin: Ok, I re-used the more common sysroot definition to mean something for the build machine... |
| # 21:54:33 |
y_morin |
mingwandroid: to avoid two different discussions in parallel, can we stick to sysroot for now? |
| # 21:54:40 |
y_morin |
mingwandroid: OK. |
| # 21:54:47 |
mingwandroid |
ok sorry. was mid-typing. |
| # 21:55:13 |
y_morin |
mingwandroid: what is currently possible with ct-ng is to build a statically-linked toolchain: all host tools are statically linked: gcc, ar, as, ld... |
| # 21:55:37 |
y_morin |
mingwandroid: (of course that has nothing to do with whether the _target_ libraries are shared or static) |
| # 21:55:48 |
mingwandroid |
yes, of course not. |
| # 21:55:57 |
y_morin |
mingwandroid: so, if you want to build a toolchain that runs on as many hosts as possible, just build a static toolchain. |
| # 21:56:23 |
mingwandroid |
I muddied thet waters by refering to sysroot as something not on the target there! |
| # 21:57:20 |
mingwandroid |
with toolchain4, I use http://mingw-and-ndk.googlecode.com/files/i686-linux-glibc2.7-4.4.3.tar.bz2 as my compiler which is the same one Google use to build their Android NDKs, and for my Android NDKs I use an old debian chroot. |
| # 21:58:11 |
mingwandroid |
I will use the debian chroot if I want to make darwin compiler releases with ct-ng then. |
| # 21:58:53 |
y_morin |
mingwandroid: why? I expect Darwin support in ct-ng *not* to require running on Debian (although that's what I use). |
| # 21:59:35 |
y_morin |
mingwandroid: ct-ng is here to explicitly *build* a compiler for Darwin, so there would be no need for that google stuff in the end, no? |
| # 21:59:41 |
mingwandroid |
for building releases people on really old distros can run. |
| # 22:00:12 |
mingwandroid |
e.g. http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz |
| # 22:00:40 |
y_morin |
mingwandroid: that would *not* need a debian chroot at all. All that it would need is for you to build a *static* toolchain, and distribute that. Being staticAlly linked, it will run on virtually all distros. |
| # 22:01:12 |
mingwandroid |
AFAIK, there are libstdc++ issues that prevent that. |
| # 22:02:33 |
y_morin |
mingwandroid: hopefully, we've solved that! I've successfully built statically-linked toolchain, and successfully run them on many other various distros (older, much older, and more recent) |
| # 22:03:12 |
mingwandroid |
y_morin: ok great then. I was just worried because Google specifically take steps to address this matter as does BogDan with Necessitas for Linux. |
| # 22:04:04 |
mingwandroid |
..that it would likely be a problem.. but I'm happy that you reckon we'll be fine. and even if there was an issue, chroot wouldn't be a big deal anyway. |
| # 22:04:12 |
mingwandroid |
so it's 100% cool. |
| # 22:21:41 |
dprice |
So I am very vexed by a problemâ I can't work out how or if I should set CT_BUILD and/or CT_BUILD_PREFIX |
| # 22:22:09 |
dprice |
I am on an FC15 x86_64 host, targetting x86_64 |
| # 22:22:37 |
dprice |
And what I am seeing is that when crosstool tries to do the static linking check, it is using the wrong CC, so that check fails. |
| # 22:23:48 |
dprice |
It tries to invoke: x86_64-build_unknown-linux-gnu-gcc, but I don't have thatâ I have redhat's gcc |
| # 22:28:31 |
y_morin |
dprice: no, that's expected. |
| # 22:28:50 |
y_morin |
dprice: at the start of the build, crosstool creates wrapper to your system tools. |
| # 22:29:05 |
dprice |
ahh, ok. |
| # 22:29:36 |
y_morin |
dprice: short explanation: we need tools to have really unambiguous names, especially for the case your are using: target is the same as the build machine. |
| # 22:29:58 |
dprice |
I guess my root problem is: I want to statically link, but I keep getting the "you can't statically link on this host" message |
| # 22:30:08 |
y_morin |
dprice: and by creating wrapper to tools, we ensure that your system tools do not have the same name as the target tools. |
| # 22:30:21 |
dprice |
y_morin: that makes a lot of sense. |
| # 22:30:40 |
y_morin |
dprice: Ah, yes, I think we got issues on FC that were never really fixed (I do not have one here). |
| # 22:30:51 |
dprice |
ah. |
| # 22:31:28 |
y_morin |
dprice: if I give you a few test instructions, could you run them on your machine and send me the result? |
| # 22:31:35 |
dprice |
So what I did was this |
| # 22:31:41 |
y_morin |
dprice: (I still have to think of those instructions, though). |
| # 22:31:45 |
dprice |
I changed the static link line... |
| # 22:31:51 |
dprice |
So that output isn |
| # 22:31:55 |
dprice |
isn't sent to /dev/null |
| # 22:32:11 |
dprice |
and I get: crosstool-NG.sh: line 488: x86_64-build_unknown-linux-gnu-gcc: command not found |
| # 22:32:25 |
dprice |
But sure, I'm happy to try whatever. |
| # 22:32:26 |
y_morin |
dprice: Doh. :-( |
| # 22:32:35 |
y_morin |
dprice: do you have ccache installed ? |
| # 22:32:47 |
dprice |
I don't know, I didn't set up the system, but I will check |
| # 22:33:04 |
y_morin |
(IIRC, FC does install ccache by default, and breaks with ct-ng) |
| # 22:33:09 |
y_morin |
dprice: please. |
| # 22:34:31 |
dprice |
yum list installed | grep ccache comes up empty |
| # 22:35:50 |
dprice |
I am going to dump out $PATH too, to see where it might be looking for the compiler |
| # 22:36:00 |
dprice |
I did a find in my outputdir, and there is one there. |
| # 22:37:23 |
y_morin |
dprice: GTG for a little while, BBL. |
| # 22:37:30 |
dprice |
np thanks |
| # 22:41:40 |
y_morin |
dprice: in your build directory, can you run: ls -l .build/TUPLE/buildtools/bin (replace TUPLE with the actual tuple of the toolchain you are building) |
| # 22:42:05 |
y_morin |
dprice: then, pastebin the listing |
| # 22:46:01 |
dprice |
http://pastebin.com/F5PfL9Lr |
| # 22:46:38 |
dprice |
y_morin: which is weird, because it looks fine |
| # 22:46:43 |
dprice |
I must be missing something |
| # 22:47:18 |
y_morin |
dprice: can you run: cat .build/TUPLE/buildtools/bin/x86_64-build_unknown-linux-gnu-gcc |
| # 22:47:29 |
y_morin |
dprice: and paste it here on channel (it should be only two lines) |
| # 22:47:44 |
dprice |
it just runs gcc |
| # 22:47:52 |
y_morin |
dprice: just paste it, please |
| # 22:47:58 |
dprice |
#!/bin/bash |
| # 22:47:58 |
dprice |
exec '/usr/bin/gcc' "${@}" |
| # 22:48:02 |
dprice |
sorry, was getting there |
| # 22:48:17 |
y_morin |
dprice: now: file /usr/bin/gcc |
| # 22:48:30 |
dprice |
and it does run, I tried invoking it |
| # 22:49:23 |
y_morin |
dprice: please, can you run: file /usr/bin/gcc |
| # 22:49:35 |
dprice |
gcc: fatal error: no input files |
| # 22:49:36 |
dprice |
compilation terminated. |
| # 22:50:00 |
dprice |
oh sorry |
| # 22:50:05 |
y_morin |
;-) |
| # 22:50:21 |
dprice |
/usr/bin/gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped |
| # 22:50:37 |
dprice |
it's 4.6.3 |
| # 22:50:49 |
y_morin |
dprice: OK, that's not ccache. |
| # 22:51:00 |
y_morin |
That is ruled out. Sigh, that was a good candidate... :-( |
| # 22:51:09 |
dprice |
in the script, I added: which ${CT_HOST}-gcc |
| # 22:51:11 |
dprice |
and that fails |
| # 22:51:25 |
y_morin |
dprice: what version of ct-ng are you using? |
| # 22:51:31 |
dprice |
1.17 |
| # 22:51:50 |
y_morin |
dprice: Doh. It really works here. I have a toolchain that is currently building... :-( |
| # 22:51:57 |
y_morin |
dprice: can you chare your .config, please? |
| # 22:53:19 |
dprice |
sure, one second |
| # 22:54:45 |
dprice |
http://pastebin.com/fGDJ1A92 |
| # 22:54:50 |
dprice |
y_morin: http://pastebin.com/fGDJ1A92 |
| # 22:57:23 |
y_morin |
dprice: OK, I'm building here |
| # 22:57:43 |
y_morin |
dprice: OK, it breaks. |
| # 22:58:04 |
y_morin |
dprice: Not the same paths on my machine |
| # 22:58:33 |
HD_Mouse |
joins #crosstool-ng |
| # 22:59:30 |
dprice |
hmm |
| # 22:59:33 |
dprice |
I have a sinking feeling |
| # 22:59:40 |
dprice |
it might be the : in the pathname |
| # 23:00:01 |
dprice |
So my output directory is: output-x86_64-fc15:x86_64 |
| # 23:00:08 |
dprice |
and I bet that this breaking $PATH |
| # 23:00:52 |
dprice |
y_morin: before you do more, let me change that and retest |
| # 23:01:12 |
y_morin |
dprice: Ah, don't do that! |
| # 23:01:27 |
dprice |
yeah, clearly |
| # 23:01:31 |
dprice |
:p |
| # 23:03:32 |
dprice |
I've been trying to wrap all of this in a layer of automationâ and the : was just an idiotic mistake |
| # 23:03:45 |
dprice |
Seems to be building now. |
| # 23:04:16 |
dprice |
y_morin: but thanks a ton for your helpâ understanding the wrapper thing made a big difference in finding this. |
| # 23:05:06 |
y_morin |
dprice: If you get some time, could you add a check for this in ct-ng? We already do a few sanitising on paths, but we missed that one. |
| # 23:05:44 |
y_morin |
dprice: consider this a payement for my help! ;-p |
| # 23:05:55 |
y_morin |
is trying to acquire new contributors! ;-) |
| # 23:18:06 |
boucman_work |
quits : Ping timeout: 268 seconds |
| # 23:21:51 |
diorcety |
quits : Quit: Leaving. |
| # 23:23:11 |
boucman_work |
joins #crosstool-ng |
| # 23:39:03 |
y_morin |
quits : Quit: Nighty Night! |
| # 23:46:08 |
smartin |
quits : Quit: leaving |