| # 01:05:30 |
bhundven |
aneyman__: doing a build of arm-multilib-linux-uclibcgnueabi |
| # 01:09:19 |
aneyman__ |
ok, and? |
| # 01:09:29 |
aneyman__ |
it takes awhile ;) |
| # 01:10:48 |
aneyman__ |
and as the commit states, it lacks threads and anything that depends on them |
| # 01:11:11 |
aneyman__ |
there are, like, 28 multilib variants AFAIR |
| # 01:26:56 |
bhundven |
:) |
| # 01:27:20 |
bhundven |
yea, yann and I spoke of the many permutations of arm multilib back in 2012 or 2013. |
| # 01:28:03 |
bhundven |
yea, this build is definitely going to take a bit |
| # 01:28:08 |
bhundven |
pass-2 |
| # 01:28:12 |
bhundven |
currently |
| # 01:42:14 |
aneyman__ |
frankly, I don't quite understand arm-gcc developers who decided on this all-or-nothing multilib list |
| # 01:42:45 |
aneyman__ |
why not follow other architectures which have a set of allowed multilib variants and allow any selection from that set |
| # 01:43:49 |
aneyman__ |
and because of that we have no way but to also include thumb v1 variant, which does not support threading in any of the libc variants |
| # 01:44:32 |
aneyman__ |
or for that matter, armv8 which is not yet supported by uclibc-ng |
| # 02:16:23 |
bhundven |
yea |
| # 02:16:31 |
bhundven |
well, it's open-source :) |
| # 02:16:53 |
bhundven |
make a patch, send it to the patches@gcc.gnu.org |
| # 02:16:59 |
bhundven |
mailing list |
| # 02:26:38 |
aneyman__ |
afaiu, a few people did that but arm-gcc maintainer was adamant |
| # 02:27:21 |
aneyman__ |
but he seems to yield a bit now that the m-profile arm does allow specification of an exact set of multilibs ;) |
| # 02:31:13 |
bhundven |
nice |
| # 02:31:43 |
bhundven |
86min in so far on final gcc |
| # 02:32:03 |
bhundven |
I'm not too keen on having that in the travis-ci test |
| # 02:32:11 |
bhundven |
;) |
| # 02:40:52 |
bhundven |
https://pastebin.osuosl.org/39296/ |
| # 02:40:53 |
bhundven |
lol |
| # 02:41:03 |
bhundven |
*cries* |
| # 02:42:23 |
bhundven |
aneyman__: I guess, one more question |
| # 02:42:32 |
bhundven |
for the target libs and tools |
| # 02:42:41 |
bhundven |
does it build one for each multilib? |
| # 02:47:08 |
aneyman__ |
no, not yet |
| # 02:47:10 |
aneyman__ |
just the default |
| # 02:47:29 |
aneyman__ |
this is something I wanted to discuss after integrating the base framework |
| # 02:47:48 |
aneyman__ |
it is fairly easy to do with the common iterator implemented in scripts/functions |
| # 02:48:31 |
aneyman__ |
but it has to be done in each lib/tool separately |
| # 02:48:56 |
aneyman__ |
because some of them, similar to avr-libc or newlib, may be aware of multilibs already |
| # 02:49:47 |
aneyman__ |
lol, told ya - 28 multilibs :) |
| # 02:50:43 |
aneyman__ |
but it builds them just fine :) I guess most people don't rebuild their toolchains twice a day |
| # 02:52:03 |
aneyman__ |
would've been *much, much* worse if the threading was supported for all variants and we had to compile libstdc++ |
| # 02:52:45 |
aneyman__ |
and *mwaha-ha-ha* (evil laugh) use glibc, that takes 5 minutes per variant :) |
| # 02:54:20 |
bhundven |
*facepalm* |
| # 02:55:16 |
bhundven |
5 people complain about multilib not being supported, a multiplier of the few that wanted it complain on not being able to specify specific targets... |
| # 02:55:51 |
bhundven |
...it's my formula for "to support a feature or not" |
| # 02:56:41 |
bhundven |
X=5, X^3 (complainers) |
| # 02:57:59 |
bhundven |
so, final compilation time: 110 minutes and 10 seconds |
| # 02:58:07 |
bhundven |
gesh |
| # 03:03:33 |
bhundven |
aneyman__: so the problem with bumping uclibc-ng before this patchset is that you'd have to rebase -i to nuke the obstack-free patch? |
| # 03:09:33 |
aneyman__ |
not surprised, but hey, if more people dislike it, more people will complain to gcc and maybe one day we'll get a --with-multilib-list for a-profile/r-profile ARMs as well |
| # 03:10:21 |
aneyman__ |
no, just that I wanted to try rebuilding all uclibc-ng based samples |
| # 03:10:39 |
bhundven |
ok |
| # 03:10:42 |
aneyman__ |
because there may be other changes in 1.0.14 aside from obstack_free fix |
| # 03:10:47 |
bhundven |
right |
| # 03:11:18 |
bhundven |
so here are my to problems, before I keep going through all these patches to find specific issues. |
| # 03:11:24 |
bhundven |
s/to/two/ |
| # 03:11:54 |
aneyman__ |
what? we have a spell-checker/grammar-nazi bot here? :) |
| # 03:12:07 |
bhundven |
1) there are a *LOT* of patches for one PR. Some of them have nothing to do with multilib, they just fix other unrelated issues. |
| # 03:12:21 |
bhundven |
(hehe, we've had ctngbot around for a while) |
| # 03:13:07 |
bhundven |
2) going forward, this is going to make testing crosstool-ng a PITA. We really need to focus after 1.23 on testing and finding a better solution for CI |
| # 03:13:24 |
aneyman__ |
https://github.com/crosstool-ng/crosstool-ng/pull/383/commits/cf96a697c8b41e5dcfb5f5d304cd39269b7abf5d |
| # 03:13:56 |
aneyman__ |
I don't see anything aside from that (which fixed musl config.in - otherwise I wasn't able to select it in testing multilib) |
| # 03:14:16 |
aneyman__ |
you did notice that the multilib branch was based on the general "fix samples" branch, right? |
| # 03:14:24 |
bhundven |
yes |
| # 03:14:35 |
bhundven |
it was my complaint then, too. |
| # 03:15:01 |
aneyman__ |
well, I wish you reacted on the "fix samples" PR when it was posted, not 3 months later :P |
| # 03:15:14 |
bhundven |
life happens. I can't control that. |
| # 03:15:24 |
aneyman__ |
OTOH I couldn't test multilib if the base sample doesn't build |
| # 03:15:34 |
bhundven |
so many "would'a, could'a, should'a" |
| # 03:15:43 |
aneyman__ |
so I needed to fix the baseline first |
| # 03:15:46 |
bhundven |
right |
| # 03:16:19 |
aneyman__ |
I am not blaming, just explaining why one huge branch ended up on top of another not-so-small branch |
| # 03:16:49 |
bhundven |
it's hard. and really... this is my "first rodeo" as far as maintaining goes. |
| # 03:16:57 |
bhundven |
it's been an adventure |
| # 03:18:36 |
alan_o |
quits : Ping timeout: 250 seconds |
| # 03:18:38 |
aneyman__ |
I'd suggest you first review the generic "fix baseline" branch |
| # 03:18:50 |
aneyman__ |
it's smaller and less controversial, I guess |
| # 03:19:32 |
aneyman__ |
if needed, I can then rebase the multilib (but if you don't merge anything in between, it shouldn't even need rebasing if I understand Git's architecture correctly) |
| # 03:21:38 |
bhundven |
I'm looking at your tree, which is the 'fix baseline' branch? |
| # 03:25:09 |
bhundven |
hehe |
| # 03:25:10 |
bhundven |
https://github.com/crosstool-ng/crosstool-ng/pull/383/commits/cc7f7db7676b828ec3f75cea6463e62f44d1c519 |
| # 03:25:32 |
bhundven |
aneyman__: now you know why I lean on mingwandroid for mingw-w64? |
| # 03:26:00 |
bhundven |
on top of the fact that his is a contributor to mingw and msys2 |
| # 03:28:16 |
aneyman__ |
https://github.com/crosstool-ng/crosstool-ng/pull/373 |
| # 03:28:24 |
aneyman__ |
is the "unbreak samples" branch |
| # 03:28:33 |
bhundven |
ah |
| # 03:28:59 |
aneyman__ |
as to MinGWizard comment, heh, I did discuss this particular bug with mingwandroid on IRC |
| # 03:29:08 |
bhundven |
hehe |
| # 03:29:13 |
bhundven |
:D |
| # 03:29:23 |
aneyman__ |
he didn't have any immediate suggestions so he agreed with marking it borked for now |
| # 03:29:34 |
bhundven |
I got winderz10 on a vm, but I can't get anything to work right on it. |
| # 03:29:42 |
bhundven |
go figure |
| # 03:30:27 |
aneyman__ |
I don't use win except for gaming ;) |
| # 03:30:45 |
bhundven |
(all the games I play work perfectly on mac os x) |
| # 03:31:02 |
bhundven |
(but don't tell anyone else that) >.> <.< oh wait... |
| # 03:31:08 |
bhundven |
:D |
| # 03:32:12 |
bhundven |
aneyman__: ok, let's do the uclibc fix branch first, then the multilib branch. |
| # 03:32:28 |
bhundven |
honestly, you did a ton of work on this!!! |
| # 03:33:03 |
aneyman__ |
what is uclibc fix branch? |
| # 03:33:09 |
bhundven |
373 |
| # 03:33:25 |
bhundven |
"unbreak samples" |
| # 03:33:33 |
aneyman__ |
ah, it's more than uclibc fix :) |
| # 03:33:38 |
bhundven |
for sure |
| # 03:33:46 |
aneyman__ |
uclibc is just one item on that list |
| # 03:34:10 |
bhundven |
I couldn't tell you why I typed it that way |
| # 03:34:55 |
bhundven |
done |
| # 03:35:31 |
bhundven |
looks like you do have to rebase the multilib branch. I don't think github is smart enough to figure it out |
| # 03:35:54 |
aneyman__ |
ok, will do once I get home |
| # 03:36:12 |
bhundven |
cool. I'm still reviewing stuff anyways. But I did look at those and they look good. |
| # 03:36:13 |
aneyman__ |
I am still @work and I ran out of desk space to put my laptop :) |
| # 03:36:59 |
aneyman__ |
have 7 target machines, build host, PXE/console host + workstation on or under my desk :) |
| # 03:37:14 |
bhundven |
nice |
| # 03:37:27 |
aneyman__ |
I am seriously considering adding a ceiling mount for putting them :) |
| # 03:37:47 |
bhundven |
I used to have a big peice of plywood with my boards on it |
| # 03:37:57 |
bhundven |
easier to move around. keep cables clean |
| # 03:38:04 |
aneyman__ |
we are close to a release, so there's a lot of "little polishing here and there" things |
| # 03:38:11 |
aneyman__ |
I thought about doing something like that |
| # 03:38:46 |
aneyman__ |
maybe in summer when my family is going back to Russia for two months :) |
| # 03:39:31 |
bhundven |
yup. there are still little stupid bugs, like the gnugo bug and a few that jasmin-j has been waiting for me to merge |
| # 03:39:49 |
bhundven |
I should have wrote that like: |
| # 03:39:54 |
bhundven |
yup. there are still little stupid bugs, like the gnugo bug |
| # 03:40:07 |
bhundven |
and I still need to merge a few that jasmin-j has |
| # 03:40:08 |
bhundven |
been waiting for |
| # 03:42:52 |
blueness |
quits : Read error: Connection reset by peer |
| # 03:45:10 |
blueness |
joins #crosstool-ng |
| # 03:50:02 |
aneyman__ |
ok, time to go home |
| # 03:50:15 |
aneyman__ |
I'll post a rebase for multilib later tonight |
| # 05:13:51 |
blueness |
quits : Read error: Connection reset by peer |
| # 05:21:30 |
blueness |
joins #crosstool-ng |
| # 05:31:57 |
bhundven |
aneyman__: ok. I'll check that out in the morning. |
| # 06:29:41 |
dummys |
enunes: here is the full error |
| # 06:29:43 |
dummys |
https://gist.github.com/dummys/f43512cf97a2322785888d5400dfdb5f |
| # 06:29:46 |
dummys |
with the .config |
| # 06:30:01 |
dummys |
and I get the same error on every profile for arml I tried |
| # 06:30:23 |
dummys |
tested these two: [G..] arm-unknown-eabi |
| # 06:30:25 |
dummys |
[G..] arm-unknown-linux-gnueabi |
| # 06:30:52 |
dummys |
really weird that it happend on every toolchain, for me it's more a problem of the core |
| # 06:30:56 |
dummys |
of the version of the gcc |
| # 07:34:32 |
diorcety |
joins #crosstool-ng |
| # 08:21:01 |
blueness |
quits : Quit: blueness |
| # 08:49:41 |
blueness |
joins #crosstool-ng |
| # 14:25:23 |
ezuck |
joins #crosstool-ng |
| # 14:51:51 |
blueness |
quits : Quit: blueness |
| # 15:23:56 |
jyelloz |
joins #crosstool-ng |
| # 15:28:01 |
ezuck |
quits : Quit: Konversation terminated! |
| # 16:22:32 |
dummys |
enunes: |
| # 16:25:30 |
y_morin |
joins #crosstool-ng |
| # 16:39:18 |
bhundven |
dummys: what distro/OS are you building on? |
| # 16:43:24 |
bhundven |
coffeeholic_: the gdb patch to fix the expat issue is in master now. Try syncing from git and try again with static toolchain |
| # 16:54:30 |
enunes |
hey bhundven , nice to see you back |
| # 16:54:38 |
bhundven |
:) |
| # 16:55:03 |
enunes |
dummys: that config is a little weird, it uses gcc 5.2.0 but 5.2.0 is not available in commit d7339f5 shown by your error |
| # 16:55:28 |
dummys |
bhundven: arch |
| # 16:55:51 |
bhundven |
dummys: ok. Could you also post the full build.log somewhere? |
| # 16:56:15 |
dummys |
I just do ct-ng build thatsall |
| # 16:56:27 |
dummys |
ok let me try on another arch, wait |
| # 16:56:56 |
bhundven |
dummys: sure, I understand. The build.log shows us a little more about the environment of the build and the details of where in the build it fails. |
| # 16:57:09 |
dummys |
ok wait |
| # 16:57:20 |
enunes |
dummys: I'll try to reproduce the error with stable 1.22.0 which has gcc 5.2.0 |
| # 16:57:51 |
dummys |
which distro? |
| # 16:57:57 |
bhundven |
enunes: the log he posted to gist was with 1.22 |
| # 16:58:04 |
bhundven |
:) |
| # 16:58:18 |
enunes |
actually it says '/usr/share/doc/crosstool-ng/crosstool-ng-1.22.0-126-gd7339f5/' |
| # 16:58:28 |
bhundven |
oh, right |
| # 16:59:02 |
bhundven |
dummys: is that an older version or did you clone from github, and switch to the 1.22 branch? |
| # 17:02:36 |
dummys |
ok trying with this one: arm-unknown-eabi |
| # 17:03:07 |
dummys |
I use the version from ARch AUR repo |
| # 17:03:22 |
enunes |
dummys: I'm on ubuntu right now, but at my main machine I use Arch too |
| # 17:03:30 |
bhundven |
dummys: I suggest downloading the released version |
| # 17:03:39 |
bhundven |
dummys: aur can lag behind |
| # 17:03:52 |
aneyman__ |
bhundven: tried building all uclibc-ng samples on top of multilib, everything built fine |
| # 17:04:14 |
bhundven |
aneyman__: cool. I'm just doing some maintenance on my local build box |
| # 17:04:27 |
aneyman__ |
I'd still suggest to pick up multilib first if possible, as it is a bigger pain to re-test :) |
| # 17:05:35 |
bhundven |
sure |
| # 17:05:44 |
dummys |
ok wait i'm trying again with crosstool-ng-git |
| # 17:05:59 |
dummys |
crosstool-ng-git-1:1.22.0.r146.gcd39285-1 |
| # 17:06:07 |
dummys |
this exact version |
| # 17:06:26 |
bhundven |
dummys: I would suggest this: |
| # 17:06:44 |
bhundven |
git clone https://github.com/crosstool-ng/crosstool-ng |
| # 17:06:49 |
bhundven |
cd crosstool-ng |
| # 17:07:08 |
bhundven |
git checkout -b 1.22 1.22 |
| # 17:07:19 |
bhundven |
will be the latest in the 1.22 branch |
| # 17:07:59 |
dummys |
yup but it's better to fix the arch problem |
| # 17:08:07 |
dummys |
then people will have a good one too no ? |
| # 17:08:22 |
bhundven |
or just download the released version of 1.22: http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.22.0.tar.bz2 |
| # 17:08:26 |
dummys |
i'm trying again, if not working, then I will report on the aur page |
| # 17:08:49 |
dummys |
-> $ cower -s crosstool 1 âµ |
| # 17:08:51 |
dummys |
aur/crosstool-ng 1.22.0-1 (80, 0.72) |
| # 17:08:53 |
dummys |
Versatile (cross-)toolchain generator |
| # 17:08:55 |
dummys |
tried both |
| # 17:08:59 |
dummys |
it's the 1.22 latest right |
| # 17:09:24 |
dummys |
didn't do a diff though |
| # 17:09:27 |
bhundven |
well, 1.22 is the "latest release", but we try to keep the master branch in git stable and usable. |
| # 17:09:53 |
bhundven |
and we are working on getting 1.23 out the door this weekend |
| # 17:10:20 |
dummys |
oh sweet |
| # 17:11:48 |
dummys |
that's cool because your building tool is using all my cores |
| # 17:11:53 |
dummys |
:) |
| # 17:12:06 |
bhundven |
although, the way things are looking... it might be delayed to early next week. |
| # 17:12:09 |
dummys |
I saw too many software that never use all the cores |
| # 17:13:05 |
blueness |
joins #crosstool-ng |
| # 17:14:57 |
blueness |
quits : Client Quit |
| # 17:16:56 |
blueness |
joins #crosstool-ng |
| # 17:17:09 |
dummys |
ok gentleman |
| # 17:17:14 |
dummys |
same problem |
| # 17:17:19 |
dummys |
on another arch install ... |
| # 17:18:26 |
dummys |
log incoming enunes |
| # 17:18:49 |
blueness |
quits : Client Quit |
| # 17:23:25 |
blueness |
joins #crosstool-ng |
| # 17:23:29 |
bhundven |
aneyman__: have you tried any cross-canadian builds? |
| # 17:24:05 |
dummys |
internal server error on bpaste for the log loool |
| # 17:25:14 |
aneyman__ |
only the one we have in the samples that's currently working |
| # 17:25:38 |
aneyman__ |
i686-w32 to nios2-elf |
| # 17:25:47 |
bhundven |
ok, I just wanted to make sure that was tested :) |
| # 17:26:06 |
aneyman__ |
well, I think we should have more cross-canadian samples :) |
| # 17:26:14 |
bhundven |
indeed! |
| # 17:26:51 |
dummys |
https://ptpb.pw/fI3a |
| # 17:26:52 |
aneyman__ |
thing is, cross-canadian samples that I may be interested in preparing/maintaining are not supported yet |
| # 17:26:53 |
dummys |
there it is |
| # 17:27:03 |
dummys |
bhundven: i will now test with your version |
| # 17:27:13 |
bhundven |
dummys: thanks! |
| # 17:27:49 |
aneyman__ |
another group in our company uses a convoluted proprietary script to create cross-toolchains targeting *-lynxos |
| # 17:28:00 |
aneyman__ |
ct-ng does not support that target (yet :)) |
| # 17:28:23 |
bhundven |
aneyman__: I know that mingwandroid was also working on supporting the *-darwin target |
| # 17:28:40 |
bhundven |
or maybe that was diorcety |
| # 17:29:10 |
dummys |
bhundven: your checkout command did not work |
| # 17:29:19 |
dummys |
-> $ git checkout -b 1.22 1.22 |
| # 17:29:21 |
dummys |
fatal: Cannot update paths and switch to branch '1.22' at the same time. |
| # 17:29:23 |
dummys |
Did you intend to checkout '1.22' which can not be resolved as commit? |
| # 17:29:33 |
bhundven |
dummys: git checkout 1.22 |
| # 17:29:37 |
bhundven |
might be the same |
| # 17:29:53 |
dummys |
yep |
| # 17:29:59 |
dummys |
just want to be sure |
| # 17:30:37 |
bhundven |
I think the first should have been: git checkout -b 1.22 origin/1.22 |
| # 17:30:46 |
bhundven |
I always forget to specify the remote |
| # 17:31:25 |
bhundven |
http://i.ebayimg.com/images/g/914AAOSwoudW8YIh/s-l300.jpg |
| # 17:33:46 |
dummys |
ok launched with your version |
| # 17:33:48 |
dummys |
will see |
| # 17:34:09 |
dummys |
do I need to do the checkout ? |
| # 17:34:14 |
dummys |
i've done checkout -b 1.22 |
| # 17:34:17 |
dummys |
it's ok you think |
| # 17:34:34 |
bhundven |
that would be the same as: git checkout -b 1.22 master |
| # 17:34:44 |
bhundven |
so that is wrong if you want to test 1.22 |
| # 17:34:48 |
dummys |
ok |
| # 17:35:21 |
bhundven |
bhundven@redbox:~/crosstool-ng$ git checkout -b 1.22 origin/1.22 |
| # 17:35:22 |
bhundven |
Branch 1.22 set up to track remote branch 1.22 from origin. |
| # 17:35:22 |
bhundven |
Switched to a new branch '1.22' |
| # 17:35:27 |
bhundven |
worked for me |
| # 17:36:53 |
dummys |
ok build relaunched |
| # 17:36:55 |
dummys |
will see |
| # 17:37:02 |
dummys |
with exacte same command as yours |
| # 17:37:40 |
bhundven |
aneyman__: it's funny going through the commits and seeing the ones I did. Pft, Like I need to review those! :P |
| # 17:38:15 |
dummys |
the version on arch aur is: |
| # 17:38:17 |
dummys |
commit cd39285ff8247ad4b69e3143bfd16a47c0743fb0 |
| # 17:38:19 |
dummys |
Merge: cd6274d 2162cbb |
| # 17:38:21 |
dummys |
Author: Bryan Hundven |
| # 17:38:23 |
dummys |
Date: Thu May 12 20:34:42 2016 -0700 |
| # 17:38:25 |
dummys |
Merge pull request #373 from stilor/unbreak-ppc-uclibc |
| # 17:38:27 |
dummys |
|
| # 17:38:29 |
dummys |
Unbreak samples |
| # 17:38:36 |
dummys |
is this not the latest one ? |
| # 17:38:42 |
bhundven |
dummys: then that is latest from git, not 1.22 |
| # 17:38:57 |
bhundven |
I forget who the maintainer of that is.. enunes ? |
| # 17:39:16 |
dummys |
so it's not "stable" ? |
| # 17:39:52 |
bhundven |
it is latest development. same as just building from the git clone without checking out a branch |
| # 17:40:03 |
bhundven |
what will be 1.23 |
| # 17:40:08 |
dummys |
oh ok |
| # 17:40:15 |
bhundven |
which, great! test it! |
| # 17:40:21 |
dummys |
but 1.22-0.1 |
| # 17:40:25 |
bhundven |
if you have problems then we can fix it easier |
| # 17:40:32 |
dummys |
is also in the aur |
| # 17:40:36 |
dummys |
and is also not working lol |
| # 17:41:08 |
bhundven |
dummys: so the "latest" does not work is what you're saying? |
| # 17:41:17 |
dummys |
yes |
| # 17:41:19 |
bhundven |
ok |
| # 17:41:25 |
dummys |
both not working on my 2 arches |
| # 17:41:44 |
dummys |
see this : https://aur.archlinux.org/packages/crosstool-ng/ |
| # 17:41:52 |
dummys |
https://aur.archlinux.org/packages/crosstool-ng-git |
| # 17:41:58 |
bhundven |
enunes: do you maintain the arch crosstool-ng packages? |
| # 17:41:59 |
dummys |
both of it is not working right now |
| # 17:42:03 |
dummys |
no it's bvalle |
| # 17:42:12 |
dummys |
and intelfx |
| # 17:46:01 |
coffeeholic_ |
Thanks, bhundven :-) |
| # 17:48:38 |
dummys |
ohhhhh bhundven |
| # 17:48:40 |
dummys |
same error bro |
| # 17:48:45 |
dummys |
you will have some work :D |
| # 17:49:05 |
dummys |
and exactly with your version |
| # 17:49:21 |
dummys |
I think I didn't need to past it, it's the same errror |
| # 17:49:33 |
dummys |
tell me what you need for debug though |
| # 17:49:49 |
dummys |
toolchain is : arm-unknown-eabi |
| # 17:55:37 |
dummys |
I need to go bhundven, tell me if you need other info to debug |
| # 17:55:47 |
dummys |
all is in my ptpb paste |
| # 18:06:23 |
aneyman__ |
bhundven: heh, I picked up mingwandroid's branch and he picked up yours? it came full cycle :) |
| # 18:06:35 |
bhundven |
:) |
| # 18:06:49 |
aneyman__ |
bhundven: I'll address the comments in the afternoon, need to finish something @work |
| # 18:07:09 |
dummys |
didyou think why it didnt work bhundven? |
| # 18:07:23 |
bhundven |
dummys: I'm setting up an arch vm |
| # 18:07:25 |
bhundven |
I'll test |
| # 18:07:40 |
dummys |
oh ok |
| # 18:14:43 |
dummys |
My patchset is from yesterday |
| # 18:14:52 |
dummys |
didnt upgraded today |
| # 18:22:19 |
bhundven |
dummys: my build is running, but will take a while |
| # 18:23:33 |
bhundven |
dummys: I'm doing arm-unknown-eabi first, as it builds the fastest. |
| # 18:39:46 |
bhundven |
dummys: I think I see the problem |
| # 18:40:05 |
bhundven |
gcc on arch is 6.1 |
| # 18:40:13 |
bhundven |
it's a little bit more picky |
| # 18:41:31 |
bhundven |
it doesn't seem to like some code in gcc-5.3.0 |
| # 18:47:01 |
bhundven |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 |
| # 18:52:33 |
bhundven |
I'm working to backport that patch in ct-ng now |
| # 19:04:24 |
enunes |
dummys: back now |
| # 19:04:45 |
enunes |
dummys: your .config built just fine here, so it should be something on your host |
| # 19:05:38 |
enunes |
bhundven: no I don't maintain the aur crosstool-ng in Arch, but I have warned the maintainer a couple of times on new version releases |
| # 19:06:28 |
bhundven |
enunes: I'm about to merge the fix, but running a build test first. |
| # 19:08:25 |
enunes |
what fix? |
| # 19:11:07 |
bhundven |
11:47 <@bhundven> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 |
| # 19:11:43 |
bhundven |
which, the build now finishes instead of breaking on the gperf issue |
| # 19:12:19 |
bhundven |
https://github.com/crosstool-ng/crosstool-ng/pull/392 |
| # 19:12:30 |
bhundven |
dummys: ^^^ fix is there |
| # 19:13:41 |
bhundven |
I'm gonna let the CI do it's thing and merge after it's done |
| # 19:14:15 |
bhundven |
enunes: does that make sense? |
| # 19:14:23 |
enunes |
oh, I get it now. makes sense, Arch is in gcc 6 |
| # 19:14:28 |
bhundven |
:D |
| # 19:14:38 |
enunes |
and I haven't seen a fail with his config here in this older Ubuntu |
| # 19:14:44 |
bhundven |
right |
| # 19:14:50 |
bhundven |
and debian is still using 5.3 |
| # 19:14:57 |
bhundven |
(which is what I use) |
| # 19:15:04 |
bhundven |
(even in sid) |
| # 19:15:36 |
bhundven |
although I could install gcc-6, but pft, why? |
| # 19:16:12 |
enunes |
bhundven: to catch these bugs before dummys :) |
| # 19:16:28 |
bhundven |
you mean, you want me to be proactive? :D |
| # 19:16:44 |
bhundven |
jk |
| # 19:17:36 |
bhundven |
I wish travis-ci let you specify using archlinux |
| # 19:17:50 |
bhundven |
but that would double the tests ran... |
| # 19:18:02 |
bhundven |
we really need to come up with a better solution for CI |
| # 19:18:24 |
bhundven |
my build on archlinux completed |
| # 19:19:37 |
enunes |
yeah CI is complicated, full of trade-offs |
| # 19:20:33 |
bhundven |
our current vector is to get a good mix of samples without taking them all, but it runs on ubuntu 14 |
| # 19:20:57 |
bhundven |
so that doesn't cover our arch/gentoo friends |
| # 19:22:10 |
bhundven |
but from my experience... working with secure embedded applications, you typically want to run on known stable/secure. So I would have thought that what we have is "good enough" |
| # 19:24:26 |
enunes |
well yeah I can say for my current company, every toolchain generated by crosstool-ng is generated in a VM provisioned for this, which happens to also be Ubuntu 14 |
| # 19:26:11 |
dummys |
cant test now, im in bar |
| # 19:27:12 |
bhundven |
heh |
| # 19:27:44 |
bhundven |
dummys: the build with that patch worked in my archlinux vm. It's currently testing in CI and hasn't merged yet. So it will be an hour or so |
| # 19:28:17 |
bhundven |
and the travis-ci cache was borked, so I had to stop the test, wipe the cache, and start over :( |
| # 19:29:23 |
bhundven |
enunes: https://github.com/mikkeloscar/arch-travis |
| # 19:40:02 |
enunes |
bhundven: cool, well I even as an Arch user am not sure if it would be so worth it, for the additional CI time I think I'd prefer to have more targets or versions tested |
| # 19:41:12 |
enunes |
I almost added avr as a target but I didn't want to increase CI time :P |
| # 19:58:08 |
Elimin8r |
joins #crosstool-ng |
| # 19:58:13 |
Elimin8er |
quits : Read error: No route to host |
| # 19:58:27 |
Elimin8r |
is now known as: Elimin8er |
| # 20:09:18 |
diorcety1 |
joins #crosstool-ng |
| # 20:10:19 |
diorcety |
quits : Ping timeout: 252 seconds |
| # 20:25:13 |
diorcety1 |
quits : Read error: Connection reset by peer |
| # 21:18:44 |
y_morin |
quits : Quit: Nighty Night! |
| # 23:13:26 |
blueness |
quits : Quit: blueness |
| # 23:13:54 |
blueness |
joins #crosstool-ng |
| # 23:28:39 |
blueness |
quits : Quit: blueness |
| # 23:29:13 |
blueness |
joins #crosstool-ng |
| # 23:30:45 |
blueness |
quits : Client Quit |
| # 23:31:12 |
luc4 |
joins #crosstool-ng |
| # 23:34:06 |
blueness |
joins #crosstool-ng |