Re: Multilib branch

[Ray Donnelly <mingw dot android at gmail dot com>]

On Sat, Jul 12, 2014 at 12:30 AM, Bryan Hundven <bryanhundven@gmail.com> wrote:
> Ray,
>
> So many good questions...
>
> List,
>
> Ray and I had started discussing updates to our WIP multilib work.
> Now we're on git, maybe I can nudge others to join in. ;)
>
> https://bitbucket.org/bhundven/crosstool-ng

Yann, are you happy to do code reviews on bitbucket or will you only
comment via the mailing list once we 'git send-email'?

It would be great if people with interest in specific architectures
could comment on and/or provide non-stub versions of
https://bitbucket.org/bhundven/crosstool-ng/commits/7fe3cf1dd807b9cd6a248cabf0c833a8a26ec94b

>
> On Fri, Jul 11, 2014 at 7:04 AM, Ray Donnelly <mingw.android@gmail.com> wrote:
>> Hi Bryan,
>>
>> Things are good thanks, hope you are well too?
>
> It's been busy. :-/
>
>> I'm taking a look now. AFAIR, there's 7 patches, some by me, some by
>> you, one mostly by Cody. How should we handle that? Ideally we'd only
>> commit our own parts I guess, but I'm not dogmatic.
>
> Go ahead and commit changes to the 'multilib' branch, as we discussed
> in IRC. 'master' is just going to track upstream.
>
>> Also, do you want to allow forced pushes? That would allow me to commit them all then
>> you could re-commit the ones you wrote I guess. FWIW, I don't mind
>> forced pushes in this situation if it leads to cleaner final patches.
>> Or we can always make new branches for either WIP or for perparing to
>> push to Yann.
>
> The 'multilib' branch is the collaboration of our work. You're more
> then welcome to have your own 'multlib-<name>-wip' branch, and just
> let me know when you are ready for merging to 'multilib', but you're a
> collaborator on that so you're also welcome to commit to 'multilib'.
>
>> Testing-wise, what do you think is a good sample config, or do you
>> have one? Just now I tested that the patchset doesn't break a
>> non-multilib Raspberry Pi target.
>
> I've been slowly working on a set of build-test scripts for
> crosstool-ng, but I've been busy, and I need a computer that can build
> ct-ng faster then my laptop.
> With that task, I'm probably going to have to instrument crosstool-ng
> a tiny bit, but that's off-topic from this thread.
>
> I think we need to test as many of the sample configs we have already
> to check for breakage.
> Then we'll create some new sample configs that have multilib targets.
>
>
>> My multilib builds in the past have been Windows build+host targeting Linux, but that requires a whole
>> load of patches that aren't to do with multilib, and I don't want to
>> muddy the waters.
>
> I'd like to see patches that fix ct-ng on windows hosts, but the long
> term issue is testing.

I wonder whether in crosstool-ng we could have a facility for patches
that are only applied for specific host or build machines? I have a
whole raft of patches that allow me to build compilers targeting lots
of different things when host+build = Windows but they are
(necessarily?) quite hacky as they work around issues such as the
failure to build {e}glibc on a case-insensitive file-system. When I
build on Linux, I also apply all these patches so at least they don't
prevent building toolchains on Linux (yeah, extensive test-suites
would be good here). I'm only guessing here but I'd bet the glibc guys
wouldn't accept them. Anyway, let's deal with Windows after multilib,
and maybe after clang+llvm and Darwin :-)

>
>> I'd also prefer to test with a Linux build+host
>> initially. I'm still not 100% sure why crosstool-ng can't build 'fake'
>> cross compilers, e.g. Linux x86_64 targeting Linux multilib. Yann
>> tried to explain it to me once, but my mind has a block where I can't
>> see where any complications are. I may try to disable the deliberate
>> failure when a native build is detected actually and see how I get on.
>
> I read this three times and don't get what your saying. Can you
> explain it a different way?
>

Well, a few hours I managed to build compilers where host+build = Arch
Linux x86_64 and target = Linux intel multilib with no difficult, so I
must have been confused as I was expecting failure. The toolchains
built and some simple test programs also worked, but the gist was that
Yann told me crosstool-ng can't be used for non-cross compilers (and I
did run into a failure in the past when trying) but to my mind,
non-cross/native seemed like a simpler situation.

>> I can push them all as soon as you tell me what branch to do it to.
>
> And they are already up!
>
>> Best regards,
>>
>> Ray.
>
> Cheers,
>
> -Bryan
>
>>
>> On Fri, Jul 11, 2014 at 7:16 AM, Bryan Hundven <bryanhundven@gmail.com> wrote:
>>> https://bitbucket.org/bhundven/crosstool-ng/branch/multilib
>>>
>>> I've added you as read/write. I wanted you to commit the changes you
>>> made from the crosstool-ng-multilib patch queue.
>>>
>>> When we feel things are ready, I'll 'git send-email' the changes to
>>> the mailing list.
>>>
>>> I hope things have been well!
>>>
>>> Cheers,
>>>
>>> -Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq