Re: Just one more thing...

[Anders F Bjöšrklund]

Walter Bright wrote:


I gather this only works with Mac OS X 10.5 "Leopard" ?

$ dmd/osx/bin/dmd hello.d
Bus error

Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?


It works with whatever came with the Mac mini install disk . I have 
no idea about other setups.


It works on Mac OS X 10.5 (confirmed with "hello.d"):
$ dmd/osx/bin/dmd dmd/samples/d/hello.d

However, "dmd" is not executable (chmod +x dmd) and
"dmd.conf" is missing (copy from "linux" directory) ?

--anders

PS. I made an installer for it with PackageMaker.app,
similar to the ones for Windows and Linux made earlier.
http://www.algonet.se/~afb/d/dmd-setup.html (DMD 1.00)
http://www.algonet.se/~afb/d/rpm-setup.html (DMD 1.00)

Re: Just one more thing...

[Walter Bright]

Anders F Björklund wrote:

Walter Bright wrote:
I suppose that explains the bus error. But I love this: "The Firebird 
build environment now uses both - just to make 100% certain". Blech. 
Anyone know for sure? I hate randomly trying things.


Set both of them... They're for the same thing, but as with all
deprecation processes it's not 100% sure everything is migrated.

MACOSX_DEPLOYMENT_TARGET=10.4
CFLAGS+=-isysroot /Developer/SDKs/MacOSX10.4u.sdk

Specifically, you want gcc and linker to use the same settings.
(especially to pick the correct OS version of the crt1 library)

But according to the documentation, this "should" work instead:
-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

--anders

PS.
I *think* it's fixed in Xcode 3.1.2, but I wouldn't bet on it...
If you're using Xcode 3.0 (from DVD), you should probably upgrade.


Hmm. I tried compiling programs by just adding -mmacosx-version-min=10.4 
 and the compiled executable is a different size, and still runs.

Re: Just one more thing...

[Walter Bright]

Anders F Björklund wrote:

-mmacosx-version-min=10.4


I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can you 
give it a try, please?

Re: Just one more thing...

[Anders F Björklund]

Walter Bright wrote:

Anders F Björklund wrote:

-mmacosx-version-min=10.4


I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can you 
give it a try, please?


You did add *both* the switches, right ? One for MDT, one for SDK.
(MDT is for choosing functions, SDK chooses headers and libraries)

-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

It still fails on Mac OS X 10.4, maybe it still used native SDK ?
(if it matters, it gets a null dereference in _malloc_initialize)

--anders

Re: Just one more thing...

[Walter Bright]

Anders F Björklund wrote:

Walter Bright wrote:

Anders F Björklund wrote:

-mmacosx-version-min=10.4


I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can 
you give it a try, please?


You did add *both* the switches, right ? One for MDT, one for SDK.
(MDT is for choosing functions, SDK chooses headers and libraries)

-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

It still fails on Mac OS X 10.4, maybe it still used native SDK ?
(if it matters, it gets a null dereference in _malloc_initialize)


Ok, I tried it with both switches now. Please give it a try.

Re: Just one more thing...

[Anders F Björklund]

Walter Bright wrote:


It still fails on Mac OS X 10.4, maybe it still used native SDK ?
(if it matters, it gets a null dereference in _malloc_initialize)


Ok, I tried it with both switches now. Please give it a try.


No luck, same problem. Might want to add "requires Mac OS X 10.5"
or something for now ? Upgraded wxD CVS to support DMD on Mac too.

--anders

Re: Just one more thing...

[Walter Bright]

Anders F Björklund wrote:

Walter Bright wrote:


It still fails on Mac OS X 10.4, maybe it still used native SDK ?
(if it matters, it gets a null dereference in _malloc_initialize)


Ok, I tried it with both switches now. Please give it a try.


No luck, same problem. Might want to add "requires Mac OS X 10.5"
or something for now ? Upgraded wxD CVS to support DMD on Mac too.


Yeah, that looks like the best strategy for the moment. It seems odd 
that there is such confusion about something that should be documented 
and straightforward.

Re: Just one more thing...

[Jacob Carlborg]

Walter Bright wrote:

Now includes Mac OSX version!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.040.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.025.zip

Expect bugs. Thread local storage isn't working on OSX, neither are 
sockets and memory mapped files (for unknown reasons).


Thanks to Sean Kelly for a lot of help on the runtime library with this.


That is terrific news

Re: Just one more thing...

[Michel Fortin]

On 2009-02-15 04:30:28 -0500, Anders F Björklund  said:


Walter Bright wrote:

Anders F Björklund wrote:

-mmacosx-version-min=10.4


I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can 
you give it a try, please?


You did add *both* the switches, right ? One for MDT, one for SDK.
(MDT is for choosing functions, SDK chooses headers and libraries)

-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

It still fails on Mac OS X 10.4, maybe it still used native SDK ?


If you specify a SDK for the compiler, you should also tell the linker 
to use the SDK.


-syslibroot /Developer/SDKs/MacOSX10.4u.sdk

Or if you're passing the linker's argument through GCC instead of 
calling the linker directly:


-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

That's all explained in the document I linked to yesterday.



(if it matters, it gets a null dereference in _malloc_initialize)


I made a diff of malloc.c (which contains _malloc_initialize) between 
10.4 and 10.5, and it looks like the rewrote half of that file, so 
there may be some differences.


But even then, if Walter is using the 10.5 SDK and isn't using anything 
specific to 10.5, I don't see where the problem could be comming from; 
especially after setting -mmacosx-version-min=10.4. When using the 10.5 
SDK, -mmacosx-version-min=10.4 will only make 10.5-only APIs 
weak-linked. When using the 10.4 SDK, it shoudn't do anything special, 
as 10.5's APIs are just not available.


I'd suggest to Walter to try adding the SDK flags to the linker. If 
that doesn't work, I'd suggest someone with 10.4 on an Intel Mac look 
for the crash report that should be in 
~/Library/Logs/CrashReporter/dmd_.crash and send it to Walter, or 
post it somewhere for everyone to analyse.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Just one more thing...

[Anders F Björklund]

Michel Fortin wrote:


It still fails on Mac OS X 10.4, maybe it still used native SDK ?


If you specify a SDK for the compiler, you should also tell the linker 
to use the SDK.


-syslibroot /Developer/SDKs/MacOSX10.4u.sdk

Or if you're passing the linker's argument through GCC instead of 
calling the linker directly:


-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

That's all explained in the document I linked to yesterday.


I thought GCC 4.0.1 and later did that for you automatically ?
i.e. passed -syslibroot to the linker when using -isysroot

--anders

Re: Just one more thing...

[Anders F Björklund]

Walter Bright wrote:


No luck, same problem. Might want to add "requires Mac OS X 10.5"
or something for now ? Upgraded wxD CVS to support DMD on Mac too.


Yeah, that looks like the best strategy for the moment. It seems odd 
that there is such confusion about something that should be documented 
and straightforward.


Must have been unlucky, or doing things "outside the dotted lines",
or both... Because usually it does just work with the MDT and SDK.

I think cross-compilation is rather transparent on Mac OS X, on the
other platforms it usually involves a full chroot or virtual machine ?

--anders

Re: Just one more thing...

[Michel Fortin]

On 2009-02-15 08:42:53 -0500, Anders F Björklund  said:


I thought GCC 4.0.1 and later did that for you automatically ?
i.e. passed -syslibroot to the linker when using -isysroot

--anders


Hum, indeed, I think you're right. Seems like this Apple documentation 
is outdated: 



Sorry 


for the confusion.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: QtD 0.1 is out!

[Eldar Insafutdinov]

Finally we managed to compile qtd for Windows. But at the very last step when 
compiling example, optlink crashed with a messagebox containing X86 registers 
content. This seems to be a blocker for qtd working on windows..

Re: QtD 0.1 is out!

[Max Samukha]

On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
 wrote:

>Finally we managed to compile qtd for Windows. But at the very last step when 
>compiling example, optlink crashed with a messagebox containing X86 registers 
>content. This seems to be a blocker for qtd working on windows..

This may be related to the famous
http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't
make extensive use of templates.

Re: QtD 0.1 is out!

[Bill Baxter]

On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 wrote:
> Finally we managed to compile qtd for Windows. But at the very last step when 
> compiling example, optlink crashed with a messagebox containing X86 registers 
> content. This seems to be a blocker for qtd working on windows..
>

Was this what you saw?
"Unexpected OPTLINK Termination at EIP=0044C37B"
http://d.puremagic.com/issues/show_bug.cgi?id=424

Whatever it was, chances are good it's a known bug.  So it would be
good to figure out which one it is that you're hitting exactly.

--bb

Re: Just one more thing...

[Jacob Carlborg]

Walter Bright wrote:

Now includes Mac OSX version!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.040.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.025.zip

Expect bugs. Thread local storage isn't working on OSX, neither are 
sockets and memory mapped files (for unknown reasons).


Thanks to Sean Kelly for a lot of help on the runtime library with this.


For those how don't know what thread local storage is used for, is this 
both D1 and D2 and what features can I expect not working because of 
thread local storage.

Re: QtD 0.1 is out!

[Bill Baxter]

On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
 wrote:
> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
>  wrote:
>
>>Finally we managed to compile qtd for Windows. But at the very last step when 
>>compiling example, optlink crashed with a messagebox containing X86 registers 
>>content. This seems to be a blocker for qtd working on windows..
>
> This may be related to the famous
> http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't
> make extensive use of templates.

It can also happen because of a single very large file.  Perhaps one
created by some sort of automatic code generation.  Anything like that
in qtd?

--bb

Re: QtD 0.1 is out!

[Eldar Insafutdinov]

Bill Baxter Wrote:

> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
>  wrote:
> > Finally we managed to compile qtd for Windows. But at the very last step 
> > when compiling example, optlink crashed with a messagebox containing X86 
> > registers content. This seems to be a blocker for qtd working on windows..
> >
> 
> Was this what you saw?
> "Unexpected OPTLINK Termination at EIP=0044C37B"
> http://d.puremagic.com/issues/show_bug.cgi?id=424
> 
> Whatever it was, chances are good it's a known bug.  So it would be
> good to figure out which one it is that you're hitting exactly.
> 
> --bb

Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". And 
yes, there is 1 quite large file, 14k lines, but because of forward reference 
and cyclic imports problems we can't split it currently.

Re: QtD 0.1 is out!

[Bill Baxter]

On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 wrote:
> Bill Baxter Wrote:
>
>> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
>>  wrote:
>> > Finally we managed to compile qtd for Windows. But at the very last step 
>> > when compiling example, optlink crashed with a messagebox containing X86 
>> > registers content. This seems to be a blocker for qtd working on windows..
>> >
>>
>> Was this what you saw?
>> "Unexpected OPTLINK Termination at EIP=0044C37B"
>> http://d.puremagic.com/issues/show_bug.cgi?id=424
>>
>> Whatever it was, chances are good it's a known bug.  So it would be
>> good to figure out which one it is that you're hitting exactly.
>>
>> --bb
>
> Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". And 
> yes, there is 1 quite large file, 14k lines, but because of forward reference 
> and cyclic imports problems we can't split it currently.

Do you compile it with inlining on?  Not positive about this, but you
may be able to cut down on the number of fixups it needs by not using
inlining.   Which file is it, anyway?

--bb

Re: QtD 0.1 is out!

[Eldar Insafutdinov]

Bill Baxter Wrote:

> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
>  wrote:
> > Bill Baxter Wrote:
> >
> >> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
> >>  wrote:
> >> > Finally we managed to compile qtd for Windows. But at the very last step 
> >> > when compiling example, optlink crashed with a messagebox containing X86 
> >> > registers content. This seems to be a blocker for qtd working on 
> >> > windows..
> >> >
> >>
> >> Was this what you saw?
> >> "Unexpected OPTLINK Termination at EIP=0044C37B"
> >> http://d.puremagic.com/issues/show_bug.cgi?id=424
> >>
> >> Whatever it was, chances are good it's a known bug.  So it would be
> >> good to figure out which one it is that you're hitting exactly.
> >>
> >> --bb
> >
> > Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". 
> > And yes, there is 1 quite large file, 14k lines, but because of forward 
> > reference and cyclic imports problems we can't split it currently.
> 
> Do you compile it with inlining on?  Not positive about this, but you
> may be able to cut down on the number of fixups it needs by not using
> inlining.   Which file is it, anyway?
> 
> --bb

it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining 
and non-inlining.

Re: QtD 0.1 is out!

[Bill Baxter]

On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
 wrote:
> Bill Baxter Wrote:
>
>> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
>>  wrote:
>> > Bill Baxter Wrote:
>> >
>> >> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
>> >>  wrote:
>> >> > Finally we managed to compile qtd for Windows. But at the very last 
>> >> > step when compiling example, optlink crashed with a messagebox 
>> >> > containing X86 registers content. This seems to be a blocker for qtd 
>> >> > working on windows..
>> >> >
>> >>
>> >> Was this what you saw?
>> >> "Unexpected OPTLINK Termination at EIP=0044C37B"
>> >> http://d.puremagic.com/issues/show_bug.cgi?id=424
>> >>
>> >> Whatever it was, chances are good it's a known bug.  So it would be
>> >> good to figure out which one it is that you're hitting exactly.
>> >>
>> >> --bb
>> >
>> > Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". 
>> > And yes, there is 1 quite large file, 14k lines, but because of forward 
>> > reference and cyclic imports problems we can't split it currently.
>>
>> Do you compile it with inlining on?  Not positive about this, but you
>> may be able to cut down on the number of fixups it needs by not using
>> inlining.   Which file is it, anyway?
>>
>> --bb
>
> it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both 
> inlining and non-inlining.

Ok.  Is it some kind of automatically generated file?  I don't see it
in the qtd repo.

--bb

Re: QtD 0.1 is out!

[Eldar Insafutdinov]

Bill Baxter Wrote:

> On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
>  wrote:
> > Bill Baxter Wrote:
> >
> >> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
> >>  wrote:
> >> > Bill Baxter Wrote:
> >> >
> >> >> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
> >> >>  wrote:
> >> >> > Finally we managed to compile qtd for Windows. But at the very last 
> >> >> > step when compiling example, optlink crashed with a messagebox 
> >> >> > containing X86 registers content. This seems to be a blocker for qtd 
> >> >> > working on windows..
> >> >> >
> >> >>
> >> >> Was this what you saw?
> >> >> "Unexpected OPTLINK Termination at EIP=0044C37B"
> >> >> http://d.puremagic.com/issues/show_bug.cgi?id=424
> >> >>
> >> >> Whatever it was, chances are good it's a known bug.  So it would be
> >> >> good to figure out which one it is that you're hitting exactly.
> >> >>
> >> >> --bb
> >> >
> >> > Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". 
> >> > And yes, there is 1 quite large file, 14k lines, but because of forward 
> >> > reference and cyclic imports problems we can't split it currently.
> >>
> >> Do you compile it with inlining on?  Not positive about this, but you
> >> may be able to cut down on the number of fixups it needs by not using
> >> inlining.   Which file is it, anyway?
> >>
> >> --bb
> >
> > it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both 
> > inlining and non-inlining.
> 
> Ok.  Is it some kind of automatically generated file?  I don't see it
> in the qtd repo.
> 
> --bb
yes, all files are automatically generated. If you wish I can upload 
it(compiled binding with headers) somewhere.

Re: QtD 0.1 is out!

[Bill Baxter]

On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov
 wrote:
> Bill Baxter Wrote:
>
>> On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
>>  wrote:
>> > Bill Baxter Wrote:
>> >
>> >> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
>> >>  wrote:
>> >> > Bill Baxter Wrote:
>> >> >
>> >> >> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
>> >> >>  wrote:
>> >> >> > Finally we managed to compile qtd for Windows. But at the very last 
>> >> >> > step when compiling example, optlink crashed with a messagebox 
>> >> >> > containing X86 registers content. This seems to be a blocker for qtd 
>> >> >> > working on windows..
>> >> >> >
>> >> >>
>> >> >> Was this what you saw?
>> >> >> "Unexpected OPTLINK Termination at EIP=0044C37B"
>> >> >> http://d.puremagic.com/issues/show_bug.cgi?id=424
>> >> >>
>> >> >> Whatever it was, chances are good it's a known bug.  So it would be
>> >> >> good to figure out which one it is that you're hitting exactly.
>> >> >>
>> >> >> --bb
>> >> >
>> >> > Yes, it is this issue: "Unexpected OPTLINK Termination at 
>> >> > EIP=0041AFFD". And yes, there is 1 quite large file, 14k lines, but 
>> >> > because of forward reference and cyclic imports problems we can't split 
>> >> > it currently.
>> >>
>> >> Do you compile it with inlining on?  Not positive about this, but you
>> >> may be able to cut down on the number of fixups it needs by not using
>> >> inlining.   Which file is it, anyway?
>> >>
>> >> --bb
>> >
>> > it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both 
>> > inlining and non-inlining.
>>
>> Ok.  Is it some kind of automatically generated file?  I don't see it
>> in the qtd repo.
>>
>> --bb
> yes, all files are automatically generated. If you wish I can upload 
> it(compiled binding with headers) somewhere.

No, that's ok.  I was just curious.  So it sounds like the best hope
is to try to find some way to split it up some.  There must be some
way it can be broken up, even if that requires turning some private
members public.  No?

--bb

Re: QtD 0.1 is out!

[Eldar Insafutdinov]

Bill Baxter Wrote:

> On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov
>  wrote:
> > Bill Baxter Wrote:
> >
> >> On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
> >>  wrote:
> >> > Bill Baxter Wrote:
> >> >
> >> >> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
> >> >>  wrote:
> >> >> > Bill Baxter Wrote:
> >> >> >
> >> >> >> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
> >> >> >>  wrote:
> >> >> >> > Finally we managed to compile qtd for Windows. But at the very 
> >> >> >> > last step when compiling example, optlink crashed with a 
> >> >> >> > messagebox containing X86 registers content. This seems to be a 
> >> >> >> > blocker for qtd working on windows..
> >> >> >> >
> >> >> >>
> >> >> >> Was this what you saw?
> >> >> >> "Unexpected OPTLINK Termination at EIP=0044C37B"
> >> >> >> http://d.puremagic.com/issues/show_bug.cgi?id=424
> >> >> >>
> >> >> >> Whatever it was, chances are good it's a known bug.  So it would be
> >> >> >> good to figure out which one it is that you're hitting exactly.
> >> >> >>
> >> >> >> --bb
> >> >> >
> >> >> > Yes, it is this issue: "Unexpected OPTLINK Termination at 
> >> >> > EIP=0041AFFD". And yes, there is 1 quite large file, 14k lines, but 
> >> >> > because of forward reference and cyclic imports problems we can't 
> >> >> > split it currently.
> >> >>
> >> >> Do you compile it with inlining on?  Not positive about this, but you
> >> >> may be able to cut down on the number of fixups it needs by not using
> >> >> inlining.   Which file is it, anyway?
> >> >>
> >> >> --bb
> >> >
> >> > it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both 
> >> > inlining and non-inlining.
> >>
> >> Ok.  Is it some kind of automatically generated file?  I don't see it
> >> in the qtd repo.
> >>
> >> --bb
> > yes, all files are automatically generated. If you wish I can upload 
> > it(compiled binding with headers) somewhere.
> 
> No, that's ok.  I was just curious.  So it sounds like the best hope
> is to try to find some way to split it up some.  There must be some
> way it can be broken up, even if that requires turning some private
> members public.  No?
> 
> --bb

It's in one file because of cyclic imports bug in dmd. The bug with optlink 
seems to be old, any chance that it's going to be fixed?

Re: Just one more thing...

[Walter Bright]

Anders F Björklund wrote:

Walter Bright wrote:


No luck, same problem. Might want to add "requires Mac OS X 10.5"
or something for now ? Upgraded wxD CVS to support DMD on Mac too.


Yeah, that looks like the best strategy for the moment. It seems odd 
that there is such confusion about something that should be documented 
and straightforward.


Must have been unlucky, or doing things "outside the dotted lines",
or both... Because usually it does just work with the MDT and SDK.


I don't know how my new Mac mini, with an utterly default install, could 
possibly be outside the dotted lines. "man gcc" lists about a thousand 
switches, none of which are -mmacosx-version-min=10.4




I think cross-compilation is rather transparent on Mac OS X, on the
other platforms it usually involves a full chroot or virtual machine ?


On Windows I can still compile for DOS .

Re: Just one more thing...

[Sean Kelly]

Jacob Carlborg wrote:

Walter Bright wrote:

Now includes Mac OSX version!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.040.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.025.zip

Expect bugs. Thread local storage isn't working on OSX, neither are 
sockets and memory mapped files (for unknown reasons).


Thanks to Sean Kelly for a lot of help on the runtime library with this.


For those how don't know what thread local storage is used for, is this 
both D1 and D2 and what features can I expect not working because of 
thread local storage.


TLS is only in D2, and I don't think any library code uses it. 
Basically, you can't declare "__thread" variables on OSX.  You *can* use 
the TLS in core.thread though (the ThreadLocal class, or 
Thread.get/setLocal).



Sean

Re: QtD 0.1 is out!

[Max Samukha]

On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter 
wrote:

>On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
> wrote:
>> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
>>  wrote:
>>
>>>Finally we managed to compile qtd for Windows. But at the very last step 
>>>when compiling example, optlink crashed with a messagebox containing X86 
>>>registers content. This seems to be a blocker for qtd working on windows..
>>
>> This may be related to the famous
>> http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't
>> make extensive use of templates.
>
>It can also happen because of a single very large file.  Perhaps one
>created by some sort of automatic code generation.  Anything like that
>in qtd?
>
>--bb

Yes, all modules are autogenerated. You are right, we probably should
think about splitting up that big file. For example, by placing enum
definitions into a separate module. It is still a less preferred
solution because it requires more tweaking of the original code
generator, which is already messy.

Re: QtD 0.1 is out!

[Eldar Insafutdinov]

Max Samukha Wrote:

> On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter 
> wrote:
> 
> >On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
> > wrote:
> >> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
> >>  wrote:
> >>
> >>>Finally we managed to compile qtd for Windows. But at the very last step 
> >>>when compiling example, optlink crashed with a messagebox containing X86 
> >>>registers content. This seems to be a blocker for qtd working on windows..
> >>
> >> This may be related to the famous
> >> http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't
> >> make extensive use of templates.
> >
> >It can also happen because of a single very large file.  Perhaps one
> >created by some sort of automatic code generation.  Anything like that
> >in qtd?
> >
> >--bb
> 
> Yes, all modules are autogenerated. You are right, we probably should
> think about splitting up that big file. For example, by placing enum
> definitions into a separate module. It is still a less preferred
> solution because it requires more tweaking of the original code
> generator, which is already messy.

The reason why is this file is big is in this bug 
http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that 
placing enums outside the class is a good idea, because enums will be exposed 
to global namespace unlike original Qt version. I have just checked, if enum A 
belongs to qt.core.Qt module you can't access it like Qt.A - which means that 
we have to keep that file big until this bug is fixed.

Re: QtD 0.1 is out!

[Bill Baxter]

On Mon, Feb 16, 2009 at 10:32 AM, Eldar Insafutdinov
 wrote:

> The reason why is this file is big is in this bug 
> http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that 
> placing enums outside the class is a good idea, because enums will be exposed 
> to global namespace unlike original Qt version. I have just checked, if enum 
> A belongs to qt.core.Qt module you can't access it like Qt.A - which means 
> that we have to keep that file big until this bug is fixed.

I guess we'll just have to wait for LDC then, because eliminating the
"too many fixups" issue in OPTLINK is completely and utterly
impossible.

--bb
;-)

Re: Just one more thing...

[Lionello Lunesu]

"Walter Bright"  wrote in message 
news:gn78ho$hm...@digitalmars.com...

Now includes Mac OSX version!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.040.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.025.zip

Expect bugs. Thread local storage isn't working on OSX, neither are 
sockets and memory mapped files (for unknown reasons).


Thanks to Sean Kelly for a lot of help on the runtime library with this.


dmd.2.025.zip has a file called "lib" (no extension) in the dmd folder. 
Sounds like a copy something \dmd\lib ? Its size is similar to gcstub.obj, 
is that it?


L. 

Re: QtD 0.1 is out!

[Eldar Insafutdinov]

Eldar Insafutdinov Wrote:

> Max Samukha Wrote:
> 
> > On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter 
> > wrote:
> > 
> > >On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
> > > wrote:
> > >> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
> > >>  wrote:
> > >>
> > >>>Finally we managed to compile qtd for Windows. But at the very last step 
> > >>>when compiling example, optlink crashed with a messagebox containing X86 
> > >>>registers content. This seems to be a blocker for qtd working on 
> > >>>windows..
> > >>
> > >> This may be related to the famous
> > >> http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't
> > >> make extensive use of templates.
> > >
> > >It can also happen because of a single very large file.  Perhaps one
> > >created by some sort of automatic code generation.  Anything like that
> > >in qtd?
> > >
> > >--bb
> > 
> > Yes, all modules are autogenerated. You are right, we probably should
> > think about splitting up that big file. For example, by placing enum
> > definitions into a separate module. It is still a less preferred
> > solution because it requires more tweaking of the original code
> > generator, which is already messy.
> 
> The reason why is this file is big is in this bug 
> http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that 
> placing enums outside the class is a good idea, because enums will be exposed 
> to global namespace unlike original Qt version. I have just checked, if enum 
> A belongs to qt.core.Qt module you can't access it like Qt.A - which means 
> that we have to keep that file big until this bug is fixed.

Anyway, I tried to place enums outside the classes, and I got:
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced

Circular import is present.

Re: Just one more thing...

[Walter Bright]

Ok, try downloading dmd1 again.

Re: Just one more thing...

[Walter Bright]

Lionello Lunesu wrote:
dmd.2.025.zip has a file called "lib" (no extension) in the dmd folder. 
Sounds like a copy something \dmd\lib ? Its size is similar to 
gcstub.obj, is that it?


eh, just delete it!

Re: QtD 0.1 is out!

[Jarrett Billingsley]

On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov
 wrote:
>> The reason why is this file is big is in this bug 
>> http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that 
>> placing enums outside the class is a good idea, because enums will be 
>> exposed to global namespace unlike original Qt version. I have just checked, 
>> if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which 
>> means that we have to keep that file big until this bug is fixed.
>
> Anyway, I tried to place enums outside the classes, and I got:
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>
> Circular import is present.

You would do well to remove all circular imports.  They make the
compiler do stupid things.

Re: Just one more thing...

[Steve Schveighoffer]

On Sat, 14 Feb 2009 12:11:38 -0800, Walter Bright wrote:

> Now includes Mac OSX version!
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.040.zip
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.025.zip
> 
> Expect bugs. Thread local storage isn't working on OSX, neither are
> sockets and memory mapped files (for unknown reasons).
> 
> Thanks to Sean Kelly for a lot of help on the runtime library with this.

WRT the new layout of lib/bin.  I know that you specify how to fix the 
permissions of the executables on the linux download page, but is it 
possible to get the files as a tarball so they do not have to be set?  Or 
to set the permissions in the zipfile (not sure about that one).  It 
seems weird that a distribution for linux has to have its permissions set 
manually.  I know it's been this way forever, but it does get annoying to 
have to twiddle with an installation every time I install it.  It 
probably isn't too much to host 2 different archives of the same file, 
one in tgz format and one in zip.

BTW, the new layout is good for cygwin users, because previous to this on 
windows, I had to remove the linux executables.  Cygwin would try to 
execute those first before finding the .exe versions.

-Steve

Re: Just one more thing...

[Dejan Lekic]

Walter Bright wrote:

Now includes Mac OSX version!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.040.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.025.zip

Expect bugs. Thread local storage isn't working on OSX, neither are 
sockets and memory mapped files (for unknown reasons).


Thanks to Sean Kelly for a lot of help on the runtime library with this.


Well done!
When can we expect 64bit version of DMD?

Re: Just one more thing...

[BCS]

Hello Dejan,


Well done!
When can we expect 64bit version of DMD?


OSX is still 32bit x86 so don't get your hopes up.

Re: Just one more thing...

[Walter Bright]

Dejan Lekic wrote:

When can we expect 64bit version of DMD?


Nobody's ever satisfied .

It has to be done sooner or later. Probably sooner.

Re: Just one more thing...

[Anders F Björklund]

Walter Bright wrote:


Must have been unlucky, or doing things "outside the dotted lines",
or both... Because usually it does just work with the MDT and SDK.


I don't know how my new Mac mini, with an utterly default install, could 
possibly be outside the dotted lines. "man gcc" lists about a thousand 
switches, none of which are -mmacosx-version-min=10.4


Me neither, seems to work for me.


I think cross-compilation is rather transparent on Mac OS X, on the
other platforms it usually involves a full chroot or virtual machine ?


On Windows I can still compile for DOS .


Is that a bug or a feature ? :-)

--anders