# 01:07:20 |
edge226 |
quits : Ping timeout: 264 seconds |
# 02:00:43 |
blueness |
quits : Ping timeout: 255 seconds |
# 02:09:25 |
blueness |
joins #crosstool-ng |
# 02:30:55 |
djerome |
quits : Remote host closed the connection |
# 05:22:02 |
edge226 |
joins #crosstool-ng |
# 06:08:05 |
y_morin |
joins #crosstool-ng |
# 06:23:59 |
y_morin |
quits : Quit: I will be back... |
# 06:38:45 |
diorcety |
joins #crosstool-ng |
# 07:10:20 |
diorcety |
quits : Read error: Connection reset by peer |
# 07:32:33 |
smartin |
quits : Ping timeout: 256 seconds |
# 07:35:18 |
smartin |
joins #crosstool-ng |
# 07:50:27 |
diorcety |
joins #crosstool-ng |
# 10:16:17 |
c0de1 |
joins #crosstool-ng |
# 10:16:21 |
c0de1 |
hey |
# 10:21:31 |
blueness |
quits : Ping timeout: 250 seconds |
# 10:22:31 |
blueness |
joins #crosstool-ng |
# 10:22:36 |
perr |
joins #crosstool-ng |
# 10:22:37 |
perr |
quits : Changing host |
# 10:22:37 |
perr |
joins #crosstool-ng |
# 10:35:36 |
perr |
quits : Quit: Leaving |
# 10:41:51 |
philenot1ound |
joins #crosstool-ng |
# 10:43:44 |
philenotfound |
quits : Ping timeout: 258 seconds |
# 13:21:32 |
strobelight |
joins #crosstool-ng |
# 14:29:51 |
diorcety |
c0de1: hy |
# 15:29:44 |
bhundven |
diorcety: hello! |
# 15:31:26 |
bhundven |
diorcety: I'm merging the multi_cc stuff today. |
# 15:32:14 |
diorcety |
bhundven: thanks !! |
# 15:32:51 |
RevChas |
joins #crosstool-ng |
# 15:34:00 |
bhundven |
I need to find someone that builds cross-canadian to test that patch set though. It can be tested post merge, as we can modify stuff to fix cross-canadian after the merge. But I still want that tested. |
# 15:34:44 |
bhundven |
I have a couple of open issues on cross-canadian, so I'm expecting some future pull requests to fix cross-canadian as well. |
# 15:35:47 |
bhundven |
kos_tom: I'm delayed on getting you prebuilts, as I need to do a stable update to fix some blocking issues in 1.21.0. So there will soon be a 1.21.1 |
# 15:36:32 |
bhundven |
kos_tom: also, could you link me to the current prebuilts? |
# 16:08:58 |
bhundven |
diorcety: if you could have mingwandroid update the one comment about the space damage in the showSamples commit, I'll merge. |
# 16:09:17 |
diorcety |
ok i will contact him |
# 16:09:25 |
bhundven |
diorcety: thanks1 |
# 16:09:36 |
bhundven |
s/1/\!/ |
# 16:10:14 |
bhundven |
diorcety: funny enough, that might have been my fault :D |
# 16:38:57 |
bhundven |
diorcety: could you also get him to checkout this bug for me: https://github.com/crosstool-ng/crosstool-ng/issues/97 |
# 16:38:57 |
bhundven |
since he does work on mingw |
# 16:38:57 |
bhundven |
I have no windows boxen |
# 16:38:57 |
bhundven |
and this one: https://github.com/crosstool-ng/crosstool-ng/issues/79 |
# 16:38:57 |
bhundven |
hehe, 97... 79... |
# 16:41:08 |
y_morin |
joins #crosstool-ng |
# 16:53:44 |
bhundven |
good evening, y_morin! |
# 16:54:50 |
y_morin |
bhundven: Heya! |
# 16:55:05 |
y_morin |
OK, git expert in the vincinity... ;-) |
# 16:55:07 |
bhundven |
did you notice I had made a #101 pull request? |
# 16:55:32 |
bhundven |
y_morin: :D |
# 16:55:42 |
y_morin |
bhundven: No, I did not... |
# 16:56:00 |
y_morin |
bhundven: That's what I find frustrating in github-style pull-requests... |
# 16:56:37 |
y_morin |
bhundven: In fact, since you sent your patch by mail, I assumed you did not have something ready to commit on your side. |
# 16:57:09 |
bhundven |
y_morin: yes, I'm still trying to figure out notifications with github and the ML |
# 16:57:30 |
y_morin |
bhundven: And I definitely do not have the reflex to look at the github stuff for pending issues/pull-requests/... |
# 16:57:37 |
y_morin |
He! |
# 16:57:49 |
y_morin |
bhundven: OK, git question for you, if you will... |
# 16:57:53 |
c0de1 |
hey |
# 16:58:00 |
bhundven |
y_morin: :) I love git questions |
# 16:58:18 |
bhundven |
rubs hands in anticipation... |
# 16:58:19 |
c0de1 |
can you add an option to completely customize --with-pkgversion |
# 16:58:30 |
c0de1 |
(to stop it adding crosstool-NG) |
# 16:58:31 |
y_morin |
bhundven: Suppose I did a git clone http://somewhere and that somewhere has a single branch, master. |
# 16:58:32 |
bhundven |
c0de1: ? |
# 16:58:46 |
bhundven |
c0de1: explain in detail |
# 16:58:48 |
y_morin |
bhundven: Then I locally cloen that already local clone. |
# 16:59:10 |
c0de1 |
basically, when building a compiler with crosstool-ng it will by default set pkgversion to something like |
# 16:59:23 |
c0de1 |
--with-pkgverson="crosstool-NG ${CT_VERSION}" etc |
# 16:59:24 |
y_morin |
bhundven: Then upstream adds a new branch, 'next'. When I pull from the first local clone, I get that new branch. |
# 16:59:38 |
y_morin |
bhundven: But if I pull from the second clone, it does not get that branch. |
# 16:59:52 |
c0de1 |
you can add something after that from the menu, but you can't remove or modify the crosstool-NG part |
# 16:59:56 |
c0de1 |
unless you edit the build sh script |
# 16:59:56 |
bhundven |
y_morin: git pull --all |
# 16:59:58 |
y_morin |
c0de1: That's customisable in the menuconfig. Except the "crosstool-NG" part is mandatory. |
# 17:00:04 |
y_morin |
bhundven: Does not work. |
# 17:00:05 |
c0de1 |
why mandatory? |
# 17:00:23 |
bhundven |
y_morin: let me re-read and think |
# 17:00:42 |
y_morin |
c0de1: Well, that's a decision I made back then, that crosstool-NG will add its ID to the gcc versionstring, so ultimate users know who to complain to. |
# 17:00:53 |
c0de1 |
"ultimate users"? |
# 17:00:59 |
c0de1 |
oh |
# 17:01:20 |
c0de1 |
I get that, but it also gets added to final executables compiled with the cross compiler |
# 17:02:50 |
bhundven |
y_morin: so, let me repeat what you say a different way |
# 17:03:20 |
c0de1 |
not a big issue :P |
# 17:03:26 |
bhundven |
y_morin: you clone: git clone --bare http://somwhere somewhere |
# 17:03:46 |
bhundven |
y_morin: then locally: git clone file:///somewhere something |
# 17:03:59 |
y_morin |
bhundven: http://code.bulix.org/wfpy3k-88470 |
# 17:04:02 |
y_morin |
bhundven: Yup |
# 17:04:41 |
y_morin |
c0de1: Well, I did not get the ct-ng version string in executables/libraries built with such a compiler (or I did not look too closely) |
# 17:04:48 |
bhundven |
y_morin: oh! |
# 17:04:51 |
y_morin |
c0de1: But if you do not like that, please send a patch. |
# 17:05:12 |
y_morin |
c0de1: Maybe bhundven Will want to change that behaviour about the version string. |
# 17:05:29 |
y_morin |
bhundven: Hehe! ;-) |
# 17:05:43 |
bhundven |
y_morin & c0de1: I've noticed issues with the version string. I'm also looking into an improvement to it. |
# 17:05:49 |
c0de1 |
i see |
# 17:05:56 |
c0de1 |
for now I just manually edit the shell script |
# 17:06:04 |
bhundven |
c0de1: you see, we switch from hg (mercurial) to git |
# 17:06:07 |
c0de1 |
i don't think many people worry about this though |
# 17:06:21 |
bhundven |
c0de1: but the version string stuff wasn't well thought out (no offense to y_morin) |
# 17:06:29 |
y_morin |
c0de1: Well, at least you do, so please send a patch. |
# 17:06:32 |
bhundven |
(and partially my fault) |
# 17:06:40 |
y_morin |
bhundven: What's the issue with that? |
# 17:06:49 |
bhundven |
y_morin: ok, I've had that issue before. |
# 17:07:13 |
bhundven |
y_morin: and what I found is that the local clone only watches the master branch because that is all that was there. |
# 17:07:22 |
c0de1 |
what about some sort of " |
# 17:07:30 |
c0de1 |
"ct-ng branding option" = on/off |
# 17:07:39 |
c0de1 |
that does complicate things though |
# 17:07:48 |
bhundven |
c0de1: no we don't want that. |
# 17:08:30 |
y_morin |
bhundven: Yep, it does not know about those branches, and I was wondering if there was a way to add it 'after-the-fact'. |
# 17:08:36 |
bhundven |
c0de1: we always want ct-ng branding or whatever is in the version string (from menuconfig) |
# 17:09:25 |
y_morin |
bhundven: Anyway, don't loose time on it, it's was jsut in-case you knew. |
# 17:09:36 |
bhundven |
y_morin: when you clone local, try: --no-single-branch |
# 17:09:51 |
y_morin |
Hmm... But the clone already exists! ;-) |
# 17:09:56 |
bhundven |
y_morin: I've never tried it, but worth experimenting |
# 17:09:57 |
y_morin |
Ok, lemme see. |
# 17:11:38 |
y_morin |
bhundven: Nope, does not even get the next branch when it already exists... |
# 17:11:44 |
bhundven |
right |
# 17:11:45 |
bhundven |
ok |
# 17:11:48 |
y_morin |
Anyway, no big deal, |
# 17:11:58 |
bhundven |
y_morin: my suggestion |
# 17:12:12 |
bhundven |
y_morin: when you clone it down the first time, clone it with: --mirror |
# 17:12:17 |
bhundven |
it will be bare |
# 17:12:29 |
y_morin |
bhundven: Ah, worth a try. |
# 17:12:33 |
bhundven |
but it will have refs to all branches and track new branches |
# 17:12:35 |
y_morin |
lemme check |
# 17:12:42 |
bhundven |
then locally clone from that |
# 17:12:48 |
bhundven |
that's what I do ;) |
# 17:13:06 |
y_morin |
He! |
# 17:13:19 |
bhundven |
it also keeps me from cloning a whole tree over and over |
# 17:13:30 |
bhundven |
I have a local mirror! :) |
# 17:13:54 |
bhundven |
in the local mirror you update with: git fetch --all |
# 17:14:10 |
bhundven |
then in the local clone: git pull --all |
# 17:14:18 |
bhundven |
but you must be on master in the local clone |
# 17:14:30 |
bhundven |
or s*$t gets f*$ked up |
# 17:15:43 |
y_morin |
bhundven: Yeah, that's about what I do, except I did not use mirror so far (because my first-level clones also contain a lot of remotes themselves) |
# 17:15:54 |
y_morin |
bhundven: So, is it possible to add remotes to a local mirror ? |
# 17:16:03 |
y_morin |
Well, I'll try, let's see... |
# 17:16:10 |
bhundven |
y_morin: yes |
# 17:16:22 |
bhundven |
but always make sure origin is the original |
# 17:16:46 |
bhundven |
I should blog my workflow |
# 17:17:08 |
bhundven |
y_morin: I can explain your problem now |
# 17:17:10 |
y_morin |
bhundven: Hm... It seems like it is doing what I do need! :-) |
# 17:17:27 |
bhundven |
in your initial clone, only the master branch is checked out |
# 17:17:41 |
bhundven |
so locally, that is the only ref that exists checked out |
# 17:17:53 |
bhundven |
then when you locally clone that |
# 17:17:57 |
bhundven |
it only picks up master |
# 17:18:18 |
bhundven |
in the original clone a new branch is availble, but not checked out |
# 17:18:31 |
bhundven |
so the local clone doesn't pick it up |
# 17:18:38 |
y_morin |
bhundven: Yep, makes perfectly sense in retrospect. |
# 17:18:51 |
y_morin |
bhundven: And yes, using a --mirror is working as I expect. |
# 17:18:53 |
bhundven |
if you went into the original clone and did: git checkout -b next origin/next; git checkout master |
# 17:18:59 |
bhundven |
the local clone would pick it up |
# 17:18:59 |
c0de1 |
o.O Don't know how to handle 'gcc-5.1.0': unknown extension |
# 17:19:33 |
bhundven |
y_morin: that make sense? |
# 17:19:37 |
y_morin |
bhundven: Note that my second-level clone also automatically inherit the remotes from the first-level clone, but they point to it, not the original remotes' upstreams. |
# 17:19:49 |
y_morin |
bhundven: Yep, totally makes sense! Thanks! :-) |
# 17:19:52 |
bhundven |
:) |
# 17:20:37 |
c0de1 |
nvm |
# 17:20:46 |
y_morin |
bhundven: I have a little script, git-clone-remotes, that automatically adds the remotes from the first-level clone, adds them to the second-level clone, but points them at the first-level clone. |
# 17:21:39 |
y_morin |
is going to re-clone all his local 'mirrors', but doign actual git mirrors! :-) |
# 17:21:50 |
y_morin |
That's gonna be quite some bandwidth... |
# 17:21:59 |
bhundven |
but will save bandwidth over time |
# 17:22:03 |
bhundven |
;) |
# 17:22:21 |
y_morin |
Yep |
# 17:22:32 |
bhundven |
expensive up front, savings over time... I'm trying to teach my boss that ;) lol |
# 17:22:41 |
y_morin |
bhundven: And it's not about saving bandwidth in the future, it's for fast acces, too. |
# 17:22:47 |
bhundven |
y_morin: yup |
# 17:23:35 |
bhundven |
moves us back to the regularly scheduled #crosstool-ng, and away from #crosstool-ng_git (OT) |
# 17:23:41 |
bhundven |
:) |
# 17:24:06 |
bhundven |
jk, it's all good in the hood |
# 17:24:40 |
y_morin |
bhundven: Yep, thanks! :-) |
# 17:25:02 |
bhundven |
y_morin: I only know about the issues with branches, is that I had to deal with deploying from a bare repo |
# 17:25:12 |
bhundven |
y_morin: sometimes a pita |
# 17:26:29 |
bhundven |
c0de1: everything good? I sort of lost track there for a minute. |
# 17:27:57 |
c0de1 |
bhundven, not sure yet, i had forgot to set the right tarball/src path. so we will see |
# 17:28:15 |
c0de1 |
but i successfully compiled a mips compiler before this, so hmm |
# 17:28:37 |
bhundven |
c0de1: ok, just let me know. |
# 17:37:36 |
diorcety |
quits : Ping timeout: 256 seconds |
# 17:41:25 |
c0de1 |
bhundven, compiling final compiler, so looks good :D |
# 17:46:26 |
c0de1 |
success :) |
# 17:54:35 |
bhundven |
c0de1: good. We're always here if you need help! |
# 17:55:07 |
c0de1 |
thanks for making ct-ng btw |
# 17:55:12 |
c0de1 |
it's awesome :) |
# 17:55:22 |
bhundven |
y_morin: ^^^ |
# 17:57:23 |
bhundven |
c0de1: I take no credit for that, but I will yield it to y_morin. |
# 17:57:34 |
c0de1 |
okay |
# 17:58:40 |
RevChas |
OK, I have my cross compiler built and working and I've managed to build a new kernel with the cross compiler. Now I need to build the compiler libraries and gcc compiler that I'll stand up in the target. I have used the populate script to create a working sysroot to install everything into. |
# 18:01:41 |
RevChas |
When I try to configure MPFR for build, it keeps on crapping out. The configure script keeps saying that ld.bfd keeps erroring out saying it can't find /lib64/libc.so.6, even though I've told it to use --with-sysroot |
# 18:05:11 |
RevChas |
The build machine is a 32 bit host that doesn't have 64 libraries available, so I'm built a cross compiler to transition us to 64 bit. |
# 18:43:13 |
RevChas |
Figured out that setting CFLAGS with --sysroot=/home/tc/dev/workingroot will use the populated sysroot. |
# 18:45:31 |
diorcety |
joins #crosstool-ng |
# 19:11:43 |
bhundven |
RevChas: ah, ok. Now I understand what you were saying |
# 19:11:58 |
bhundven |
RevChas: glad you figured it out! |
# 19:27:18 |
bhundven |
RevChas: it may be helpful for us to add another kconfig option to specify a sysroot if you have a populated sysroot, and have it automatically add --sysroot= to the CFLAGS. |
# 19:27:31 |
bhundven |
if that option is populated (no pun intended) |
# 19:29:09 |
bhundven |
say: CT_TOOLCHAIN_POPULATED_SYSROOT=/path/to/populated/sysroot |
# 19:31:03 |
bhundven |
if [ -n ${CT_TOOLCHAIN_POPULATED_SYSROOT} -a -d ${CT_TOOLCHAIN_POPULATED_SYSROOT} ]; then CT_TARGET_CFLAGS+="--sysroot=${CT_TOOLCHAIN_POPULATED_SYSROOT}; fi |
# 19:31:17 |
bhundven |
something like that |
# 21:40:04 |
strobelight |
quits : Quit: strobelight |
# 21:44:00 |
RevChas |
I have thw libraries built, but when I try to compile new compiler with the cross compiler it fails. I suspect that it fails because it tries to build with the 32-bit only g++ compiler on this host. I configured the cross compiler *and* the new compiler with --enable-languages=c, but the new compiler build still tries to use the native g++. |
# 21:45:11 |
RevChas |
I haven't been able to find a "No just no g++, but fuck no g++" switch anywhere. |
# 21:46:05 |
y_morin |
quits : Quit: Nighty Night! |
# 21:48:18 |
bhundven |
RevChas: c++ is the new default gcc compiler |
# 21:48:32 |
bhundven |
I think that was in 4.9 |
# 21:49:00 |
bhundven |
nope, 4.8: https://gcc.gnu.org/gcc-4.8/changes.html |
# 21:49:21 |
bhundven |
"GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003." |
# 21:49:51 |
bhundven |
So you need c++ enabled in your initial cross-compiler |
# 21:50:15 |
RevChas |
Time to rebuild the cross-compiler. |
# 21:50:23 |
bhundven |
:) |
# 21:51:26 |
bhundven |
In hindsight, it really is amazing how much gcc has changed from 4.7 to 5.1 |
# 21:51:27 |
RevChas |
bhundven: I was hoping to lighen things up by having a C only compiler. If C was good enough for Kernighan and Ritchie and Jesus, it's good enough for me. |
# 21:51:51 |
bhundven |
no cobol support? lol |
# 21:52:05 |
bhundven |
jk |
# 21:52:38 |
bhundven |
or java support (which I only know of a few apps that actually support being built by gcc-gcj) |
# 22:00:12 |
RevChas |
bhundven: Cobol and java make the baby Jesus cry. |
# 22:00:36 |
bhundven |
Bwahahahaha |
# 22:01:32 |
bhundven |
Well, don't cry too soon, the gcc/cobol port died 7 years ago |
# 22:01:58 |
bhundven |
http://cobolforgcc.sourceforge.net/ |
# 22:02:07 |
bhundven |
(links or it didn't happen) |
# 22:03:11 |
bhundven |
I may have started on a ti-99/4a, but I really cut my teeth on an AS/400 (with JCL/Cobol) |
# 22:03:47 |
bhundven |
I don't miss either |
# 22:04:57 |
feepbot |
quits : Ping timeout: 264 seconds |
# 22:07:49 |
feepbot |
joins #crosstool-ng |
# 22:09:11 |
RevChas |
I'm just hoping like hell that simply adding C++ to the crosstool-ng config and a rebuild will save me. |
# 22:13:40 |
bhundven |
RevChas: it should |
# 22:13:52 |
bhundven |
RevChas: keyword: should |
# 22:14:26 |
bhundven |
RevChas: I can admit though, that I've never attempted to do a cross-compiler that way (cross-canadian?) |
# 22:14:30 |
RevChas |
bhundven: I made sure that the candles are black, the silver knife is hsarp and the goat is a virgin. Wish me luck. |
# 22:14:42 |
RevChas |
s/hsarp/sharp/ |
# 22:14:55 |
bhundven |
you forgot about the wind direction and moon phase |
# 22:15:05 |
bhundven |
:P |
# 22:15:09 |
RevChas |
ctngbot: Stop that. |
# 22:15:42 |
RevChas |
bhundven: That's just a matter of breaking out the compass. |
# 22:15:49 |
bhundven |
heh |
# 22:33:52 |
mingwandroid |
joins #crosstool-ng |
# 23:05:01 |
mingwandroid |
quits : Remote host closed the connection |