I've been unable to compile gcc patches to gcc-4.8 on OSX, I get an error in thread.d, an assert "Not implemented", it seems that it is not getting the right version while compiling initStack() and fiber_entryPoint(), if I comment out both asserts, as expected it breaks the library and whenever I compile anything (even an empty main()) I get a lot of errors about undefined symbols similar to _D11TypeInfo_Am6__initZ in libgphobos2.a

It is gdc supported under OSX??

On Friday, 1 November 2013 at 06:08:53 UTC, kahuna wrote:
> I've been unable to compile gcc patches to gcc-4.8 on OSX, I get an error in thread.d, an assert "Not implemented", it seems that it is not getting the right version while compiling initStack() and fiber_entryPoint(), if I comment out both asserts, as expected it breaks the library and whenever I compile anything (even an empty main()) I get a lot of errors about undefined symbols similar to _D11TypeInfo_Am6__initZ in libgphobos2.a
>
> It is gdc supported under OSX??

I have tried to compile branch v1.x with gcc-4.7.3 and although I get no error on thread.d (I get some bad references to direct d_name.ptr, fixed removing .ptr) but I get the same undefined symbols when compiling with gdc, so I understand that OSX is not currently working, at least on 10.8.5 and Xcode 5

On Friday, 1 November 2013 at 07:51:09 UTC, kahuna wrote:
> I have tried to compile branch v1.x with gcc-4.7.3 and although I get no error on thread.d (I get some bad references to direct d_name.ptr, fixed removing .ptr) but I get the same undefined symbols when compiling with gdc, so I understand that OSX is not currently working, at least on 10.8.5 and Xcode 5

Are you sure it's not because Xcode 5 has clang as the default compiler, even symlinking g++ to clang++? It may therefore be that gcc won't compile with clang, and installing GCC proper will solve your problem.

On Friday, 1 November 2013 at 10:03:42 UTC, Joseph Rushton Wakeling wrote:
> On Friday, 1 November 2013 at 07:51:09 UTC, kahuna wrote:
>> I have tried to compile branch v1.x with gcc-4.7.3 and although I get no error on thread.d (I get some bad references to direct d_name.ptr, fixed removing .ptr) but I get the same undefined symbols when compiling with gdc, so I understand that OSX is not currently working, at least on 10.8.5 and Xcode 5
>
> Are you sure it's not because Xcode 5 has clang as the default compiler, even symlinking g++ to clang++? It may therefore be that gcc won't compile with clang, and installing GCC proper will solve your problem.

I have compiled it gcc-4.8.1 but anyway it should bootstrap itself, shouldn't it?

On Friday, 1 November 2013 at 10:03:42 UTC, Joseph Rushton Wakeling wrote:
> On Friday, 1 November 2013 at 07:51:09 UTC, kahuna wrote:
>> I have tried to compile branch v1.x with gcc-4.7.3 and although I get no error on thread.d (I get some bad references to direct d_name.ptr, fixed removing .ptr) but I get the same undefined symbols when compiling with gdc, so I understand that OSX is not currently working, at least on 10.8.5 and Xcode 5
>
> Are you sure it's not because Xcode 5 has clang as the default compiler, even symlinking g++ to clang++? It may therefore be that gcc won't compile with clang, and installing GCC proper will solve your problem.

I have compiled it with gcc-4.8.1, but anyway it should bootstrap itself.

On 02/11/13 04:56, kahuna wrote:
> I have compiled it with gcc-4.8.1, but anyway it should bootstrap itself.

Just to avoid doubt, I want to be absolutely clear what you're doing here.

When you say "with gcc-4.8.1" are you talking about the actual GCC compiler you already have installed on your system, or the GCC source that you're using with GDC?

The point is that once those gcc sources are built, that will indeed bootstrap compilation of the rest of gcc and GDC; but you need a working compiler that can compile the core of GCC itself, and it's unlikely clang can do that.  It's likely with Xcode 5 that the system compiler is clang and not gcc, and that the gcc/g++ commands are symlinked to clang.

Just to test, can you try typing g++ --version in a terminal window and see what it outputs?

Hope that I don't sound condescending here, I'm just trying to make sure that I don't misunderstand you and that I understand properly how your system is set up.

On Saturday, 2 November 2013 at 10:49:50 UTC, Joseph Rushton Wakeling wrote:
> On 02/11/13 04:56, kahuna wrote:
>> I have compiled it with gcc-4.8.1, but anyway it should bootstrap itself.
>
> Just to avoid doubt, I want to be absolutely clear what you're doing here.

Kahuna, any news? Did you manage to get your build working?

On Sunday, 3 November 2013 at 05:51:07 UTC, Joseph Rushton Wakeling wrote:
> On Saturday, 2 November 2013 at 10:49:50 UTC, Joseph Rushton Wakeling wrote:
>> On 02/11/13 04:56, kahuna wrote:
>>> I have compiled it with gcc-4.8.1, but anyway it should bootstrap itself.
>>
>> Just to avoid doubt, I want to be absolutely clear what you're doing here.
>
> Kahuna, any news? Did you manage to get your build working?

Sorry I was without internet during the weekend (THE HELL ON EARTH!!! :-), I'm using gcc 4.8.1 binary distribution for osx to compile gcc-4.8.2, I also tried gcc-4.7.0 to compile latest gcc-4.7.3 with identical result (the gcc-4.8.1 was downloaded from http://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/4.8.1/) and gcc-4.7.0 from the equivalent place for it.

the problem seems to be related to double underscore and simple underscore during the linking process. Compiling an empty main() and then linking produce lot of errors similar to

Undefined symbols for architecture x86_64:
  "_D10TypeInfo_a6__initZ", referenced from:
….

if I make

nm libgphobos.a | grep D10TypeInfo_a6__initZ

I get:

                 U _D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ
00000000000002b0 S __D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ

so maybe the compiler is failing when building the libgphobos.a

With gcc-4.8.2 I get the equivalent for libgphobos2.a

maybe the linker for OSX is not compatible with something deep inside gdc?? I have compiled c++ and c code without problems using those compilers and the references for c++ classes are correctly constructed with double underscore prefix..

Any idea?

On Sunday, 3 November 2013 at 05:51:07 UTC, Joseph Rushton Wakeling wrote:
> On Saturday, 2 November 2013 at 10:49:50 UTC, Joseph Rushton Wakeling wrote:
>> On 02/11/13 04:56, kahuna wrote:
>>> I have compiled it with gcc-4.8.1, but anyway it should bootstrap itself.
>>
>> Just to avoid doubt, I want to be absolutely clear what you're doing here.
>
> Kahuna, any news? Did you manage to get your build working?

Sorry I was without internet during the weekend (THE HELL ON EARTH!!! :-), I'm using gcc 4.8.1 binary distribution for osx to compile gcc-4.8.2, I also tried gcc-4.7.0 to compile latest gcc-4.7.3 with identical result (the gcc-4.8.1 was downloaded from http://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/4.8.1/) and gcc-4.7.0 from the equivalent place for it.

the problem seems to be related to double underscore and simple underscore during the linking process. Compiling an empty main() and then linking produce lot of errors similar to

Undefined symbols for architecture x86_64:
  "_D10TypeInfo_a6__initZ", referenced from:
….

if I make

nm libgphobos.a | grep D10TypeInfo_a6__initZ

I get:

                 U _D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ
00000000000002b0 S __D10TypeInfo_a6__initZ
                 U _D10TypeInfo_a6__initZ

so maybe the compiler is failing when building the libgphobos.a

With gcc-4.8.2 I get the equivalent for libgphobos2.a

maybe the linker for OSX is not compatible with something deep inside gdc?? I have compiled c++ and c code without problems using those compilers and the references for c++ classes are correctly constructed with double underscore prefix.

In fact after searching for this specific behavior I found this:

http://forum.dlang.org/thread/4DE7ABFD.5000808@cam.ac.uk

so it seems that this has been already reported a year ago without any fix since then :-/

Any idea?

More info on this,

It seems that latest version available from bitbucket do compile at least inside 4.7.3 without problems, I'll try to compile libgphobos2.a from this version using the new gdc from and check if it is a problem with gdc or with the libgphobos2 Makefiles.

Regards