Sorry for a long chain on OSX. But one last unresolved symbol from make
check-d: "_d_osx_image_init". Is it just a placeholder or is it hidden
somewhere. Does gdc still need the code to set setup gc scanning? How
is TLS on OSX? - if not ready, would emutls work?
--
Dan
Dan Olson writes:
> Looks like I need to track down missing symbols from rt.tlsgc now. I
> think it is becoming a fun puzzle :-) The arm stuff can wait.
How do I tell gdc that OS X needs target specific underscore "_" prefix
added to pragma(mangle, name)? thread.d uses
core.internal.traits.exte
Dan Olson writes:
> "Iain Buclaw via D.gnu" writes:
>
>> On 4 June 2015 at 17:33, Dan Olson via D.gnu
>> wrote:
>>
>> As a sanity step before switching to gcc-6, tried to build gdc-5
>> branch
>> on OSX X86_64 with gcc-5.1. I must be missing something because no
>> versions
"Iain Buclaw via D.gnu" writes:
> On 4 June 2015 at 17:33, Dan Olson via D.gnu
> wrote:
>
> As a sanity step before switching to gcc-6, tried to build gdc-5
> branch
> on OSX X86_64 with gcc-5.1. I must be missing something because no
> versions are satisfied for thread.d fi
On Thursday, 4 June 2015 at 18:35:45 UTC, Johannes Pfau wrote:
If you mean adding support to the same binary toolchain
package: I don't think that will work. Multilib requires
similar systems, it's probably not possible to mix
linux+libphobos and baremetal builds.
Indeed. I completely gloss
Am Thu, 04 Jun 2015 04:05:39 +
schrieb "Mike" :
> On Wednesday, 3 June 2015 at 12:54:32 UTC, Johannes Pfau wrote:
> >
> > That's correct. All ARM GCC compilers can generate code for all
> > ARM variants (the hf compiler can generate softfloat code and
> > the softfloat compiler can generate
On 4 June 2015 at 17:33, Dan Olson via D.gnu wrote:
> "Iain Buclaw via D.gnu" writes:
>
> > All PRs should be based on master, and they get trickled down to
> > release branches as needed.
> >
> > Master only works (or at least, has been tested) with the development
> > snapshot listed in gcc.ve
"Iain Buclaw via D.gnu" writes:
> All PRs should be based on master, and they get trickled down to
> release branches as needed.
>
> Master only works (or at least, has been tested) with the development
> snapshot listed in gcc.version. Which would be version gcc-6 now.
Ok, thanks.
As a sanity
On Thu, 04 Jun 2015 06:49:00 -0700, Dan Olson wrote:
> ketmar writes:
>
>> On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:
>>
>>> Starting a pull request for ARM and grabbed gdc master, but not sure
>>> what gcc it likes. I tried gcc-5.1 but
>>>
>>> $ ./setup-gcc.sh ../gcc-5.1.0 found gcc
On 4 June 2015 at 15:49, Dan Olson via D.gnu wrote:
> ketmar writes:
>
> > On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:
> >
> >> Starting a pull request for ARM and grabbed gdc master, but not sure
> >> what gcc it likes. I tried gcc-5.1 but
> >>
> >> $ ./setup-gcc.sh ../gcc-5.1.0 found
ketmar writes:
> On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:
>
>> Starting a pull request for ARM and grabbed gdc master, but not sure
>> what gcc it likes. I tried gcc-5.1 but
>>
>> $ ./setup-gcc.sh ../gcc-5.1.0 found gcc version 5 This version of GCC
>> (5) is not supported.
>
> make
On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:
> Starting a pull request for ARM and grabbed gdc master, but not sure
> what gcc it likes. I tried gcc-5.1 but
>
> $ ./setup-gcc.sh ../gcc-5.1.0 found gcc version 5 This version of GCC
> (5) is not supported.
make sure that you switched to '
Starting a pull request for ARM and grabbed gdc master, but not sure
what gcc it likes. I tried gcc-5.1 but
$ ./setup-gcc.sh ../gcc-5.1.0
found gcc version 5
This version of GCC (5) is not supported.
--
Dan
13 matches
Mail list logo
