www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Working LDC iOS (iPhone) on github

reply Dan Olson <zans.is.for.cans yahoo.com> writes:
I think the LDC + iOS stuff it is working well enough that others might
have fun with it too.  I made a fork of ldc/druntime on github and
pushed up changes into branch ios-2.064.  It is based on ldc merge-2.064
branch.  You will find very few changes were needed to get this far.  It
has been mostly a game of finding the right recipe and stubbing out
missing functions for iOS.

What can you do with it?  Well, as far as I know, most of D 2.064
appears to work with the exception of exceptions (that came out nice)
and thread locals.  I am sure there are many pits and holes to fall into
though.

In general:
- TLS support not available so I disabled for now
- Threads "work", but there are unfinished pieces and a wumpus hiding
  here (e.g. not sure what gc will do when it triggers)
- You can throw exceptions, but they have a tragic ending
- debug info does not work and -g causes link warnings
- things are hardcoded for iOS in a few places, so this branch may not
  work as a native compiler).  For example, I had to hardcode real type
  as a 64-bit double (dmd uses host's long double type for real)

To compile the C portions of druntime/phobos, you will need an iPhone
SDK downloaded from Apple, which means you need to use OSX (mac) as
the host.  To actually run on hardware (iPhone 4 in my case) I signed up
as an iOS developer.  D objs and libs can then be added to an Xcode
project and run in the debugger.

Follow normal ldc build instructions on D wiki with some differences
below.

http://wiki.dlang.org/Building_LDC_from_source.

Must use llvm-3.4 or newer.  I am confguring llvm with all targets
enabled (llvm/configure with no options).

$ git clone --recursive https://github.com/smolt/ldc.git
$ mkdir thumb7-ios-ldc
$ cd thumb7-ios-ldc
$ cmake -DD_FLAGS='-w;-d;-mtriple=thumbv7-apple-ios5.0.0;-mcpu=cortex-a8;-disable-fp-elim;-float-abi=so
tfp;-vectorize-slp' -DD_FLAGS_DEBUG='' -DD_FLAGS_RELEASE='-Os;-release'
-DTARGET_C_FLAGS='-target armv7-apple-darwin -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/S
Ks/iPhoneOS7.0.sdk' ../ldc
$ make

Then to compile a simple program with D as the main:

$ cat <<XYZZY >hello.d
import std.stdio;

void main()
{
    writeln("Hello from D");
}
XYZZY

$ thumb7-ios-ldc/bin/ldc2 -mtriple=thumbv7-apple-ios5.0.0 -disable-fp-elim
-float-abi=softfp -Os -c hello.d

Make a simple (empty) Xcode project for iOS and remove the objc main.m
(or disabled it).  Then add the resulting hello.o plus
thumb7-ios-ldc-3.4/lib/libphobos-ldc-debug.a.  There are no debug
symbols but at least asserts are enabled, which I think is a good thing
in this new world.  Build and run.

Alternatively, you can use the objc main() and have it call an extern
(C) D function.  But remember to call rt_init() first thing.  You can do
it the objc main() as in:

int main()
{
   extern int rt_init();
   extern void someDfunc();
   if (rt_init()) {
      someDfunc();
   }

   ...

}

I hope it works for somebody besides me.  Thanks to everyone who helped
so far.
-- 
Dan
Feb 14 2014
next sibling parent "Kai Nacke" <kai redstar.de> writes:
Hi Dan!

On Friday, 14 February 2014 at 09:02:22 UTC, Dan Olson wrote:

 I think the LDC + iOS stuff it is working well enough that 
 others might
 have fun with it too.  [...]
 I hope it works for somebody besides me.  Thanks to everyone 
 who helped
 so far.


I am really impressed!!!!

Regards,
Kai
Feb 14 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-02-14 10:02, Dan Olson wrote:

 I think the LDC + iOS stuff it is working well enough that others might
 have fun with it too.  I made a fork of ldc/druntime on github and
 pushed up changes into branch ios-2.064.  It is based on ldc merge-2.064
 branch.  You will find very few changes were needed to get this far.  It
 has been mostly a game of finding the right recipe and stubbing out
 missing functions for iOS.

 What can you do with it?  Well, as far as I know, most of D 2.064
 appears to work with the exception of exceptions (that came out nice)
 and thread locals.  I am sure there are many pits and holes to fall into
 though.

 In general:
 - TLS support not available so I disabled for now


If TLS is not natively supported, can it be emulated like DMD currently 
does on OS X?


 - Threads "work", but there are unfinished pieces and a wumpus hiding
    here (e.g. not sure what gc will do when it triggers)
 - You can throw exceptions, but they have a tragic ending
 - debug info does not work and -g causes link warnings
 - things are hardcoded for iOS in a few places, so this branch may not
    work as a native compiler).  For example, I had to hardcode real type
    as a 64-bit double (dmd uses host's long double type for real)




 I hope it works for somebody besides me.  Thanks to everyone who helped
 so far.


This sounds great :)

-- 
/Jacob Carlborg
Feb 14 2014
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 14 February 2014 at 19:58:45 UTC, Jacob Carlborg wrote:

 On 2014-02-14 10:02, Dan Olson wrote:

 In general:
 - TLS support not available so I disabled for now


 If TLS is not natively supported, can it be emulated like DMD 
 currently does on OS X?


Yes, why can't you just use the TLS support in druntime's 
rt/sections_osx.d?  Is it that different on iOS?

Nice work, looking forward to checking it out when I try ARM on 
Android.
Feb 14 2014
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Joakim" <joakim airpost.net> writes:


 On Friday, 14 February 2014 at 19:58:45 UTC, Jacob Carlborg wrote:

 If TLS is not natively supported, can it be emulated like DMD
 currently does on OS X?


 Yes, why can't you just use the TLS support in druntime's
 rt/sections_osx.d?  Is it that different on iOS?


Hi Joakim,

David suggested we could do that with ldc.  I think it is a good approach.

http://forum.dlang.org/thread/m2d2k79zsl.fsf comcast.net?page=3#post-mailman.287.1389372405.15871.digitalmars-d-ldc:40puremagic.com
Feb 14 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 15 Feb 2014, at 7:58, Dan Olson wrote:

 David suggested we could do that with ldc.  I think it is a good 
 approach.

 http://forum.dlang.org/thread/m2d2k79zsl.fsf comcast.net?page=3#post-mailman.287.1389372405.15871.digitalmars-d-ldc:40puremagic.com


The big question is how to best implement it, though.

 From an LDC perspective, the best would be to add support for emitting 
the TLS variables into a bracketed section and inserting runtime calls 
to access them directly to LLVM; then none of the LDC code (resp. the 
generated LLVM IR) would actually have to change.

That might be too much work for this option to be feasible, though – I 
never really looked at how the various targets lower TLS accesses 
(besides Win32/MinGW, where I contributed a few small fixes).

I suppose the best way to go about this would simply be to ask for 
advice on llvm-dev, probably somebody can judge the involved trade-offs 
much better than I can.

David
Feb 15 2014
parent reply "Jacob Carlborg" <doob me.com> writes:
On Saturday, 15 February 2014 at 15:13:07 UTC, David Nadlinger 
wrote:


 The big question is how to best implement it, though.

 From an LDC perspective, the best would be to add support for 
 emitting the TLS variables into a bracketed section and 
 inserting runtime calls to access them directly to LLVM; then 
 none of the LDC code (resp. the generated LLVM IR) would 
 actually have to change.


At least DMD had some problems with bracketed sections with the 
linker. DMD doesn't use bracketed sections anymore. Why do you 
need bracketed sections? At least OS X has API's available to 
access a specific sections. I would assume iOS also has does 
API's.

Would it be possible to output OS X native TLS for iOS? Does LLVM 
allow that? If that's possible we could experiment with adding 
the TLS code from the dynamic linker to druntime and see what 
happens. Theoretically it should work. It don't think the dynamic 
linker does anything that a regular application can't do.

--
/Jacob Carlborg
Feb 16 2014
parent reply David Nadlinger <code klickverbot.at> writes:
On 16 Feb 2014, at 13:43, Jacob Carlborg wrote:

 On Saturday, 15 February 2014 at 15:13:07 UTC, David Nadlinger wrote:

 From an LDC perspective, the best would be to add support for
 emitting the TLS variables into a bracketed section and inserting
 runtime calls to access them directly to LLVM; then none of the LDC
 code (resp. the generated LLVM IR) would actually have to change.


 At least DMD had some problems with bracketed sections with the
 linker. DMD doesn't use bracketed sections anymore. Why do you need
 bracketed sections? At least OS X has API's available to access a
 specific sections.


Sorry, yes, I just intended to write "special section".

But as a side note, Darwin's dyld is more or less alone in offering
that functionality. On other OSes, DMD still uses bracketed sections
for various tasks.


 Would it be possible to output OS X native TLS for iOS? Does LLVM
 allow that? If that's possible we could experiment with adding the TLS
 code from the dynamic linker to druntime and see what happens.
 Theoretically it should work. It don't think the dynamic linker does
 anything that a regular application can't do.


I was thinking about that as well, yes. In theory, it should be
possible to adapt the code in LLVM without too much of a hassle (I
don't think there would be any problems with x86-specific relocations
or so), but as I said, I haven't looked into how the TLS sections are
emitted when writing to Mach-O at all.

Another thing to keep in mind would be that we probably can't use some
of the APIs due to App Store restrictions…

David
Feb 16 2014
parent "Jacob Carlborg" <doob me.com> writes:
On Sunday, 16 February 2014 at 13:19:00 UTC, David Nadlinger 
wrote:


 Sorry, yes, I just intended to write "special section".

 But as a side note, Darwin's dyld is more or less alone in 
 offering
 that functionality. On other OSes, DMD still uses bracketed 
 sections
 for various tasks.


Yes, exactly. But where talking iOS and OS X here ;)


 I was thinking about that as well, yes. In theory, it should be
 possible to adapt the code in LLVM without too much of a hassle 
 (I
 don't think there would be any problems with x86-specific 
 relocations
 or so), but as I said, I haven't looked into how the TLS 
 sections are
 emitted when writing to Mach-O at all.

 Another thing to keep in mind would be that we probably can't 
 use some
 of the APIs due to App Store restrictions…


_dyld_register_func_for_add_image and other similar functions are 
documented here [1], which I assume means they are public API and 
are allowed to be used (I have not read the App Store license). 
But LDC already uses a function to iterate TLS data on OS X in 
the runtime (if its still is used) which not documented. Phobos 
also uses _NSGetEnviron which is not documented. The first could 
be replaced with some of these functions [1]. The second could 
perhaps be replaced with a C main function accepting the 
environment variables as a third parameter.

BTW, the _dyld_register_func_for_add_image is not safe to use 
with dynamic libraries, since it's not possible to unregister the 
callback. There is another undocumented function that can be used 
instead.

[1] 
https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html

--
/Jacob Carlborg
Feb 16 2014
prev sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
Jacob Carlborg <doob me.com> writes:


 If TLS is not natively supported, can it be emulated like DMD
 currently does on OS X?


David talked about doing something like that.  BTW (and aside), does dmd
still emulate tls on OSX?  If so, is someone planning to switch it to
OSX's thread locals?

Jacob, it looks like you have been playing with D on Mac for awhile.  I
searched D forums for iOS or Mac stuff and your name comes up.  I think
as a next step (pun intended) it would be cool to try something you have
done to interface D with the objc world.  For now, I am just creating C
functions as needed to glue objc messages to D.

Also started playing some with the ObjC Runtime calls like

  objc_msgSend(obj, sel_registerName("release"))

to do stuff like

  [obj release];

That could go along way with some handy wrapper functions.  Then there
is the project I think you mentioned to make D compiler directly support
objc interfaces.  Would it be much work to fold it into the current
compiler?

Anyway, looking forward to any tools or thoughts you have.  For now,
exception handling seems the most useful missing feature.  So I am
looking at that.
-- 
Dan
Feb 14 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-02-15 07:44, Dan Olson wrote:


 David talked about doing something like that.  BTW (and aside), does dmd
 still emulate tls on OSX?


Yes, it still emulates. I think we need to decide if we are willing to 
remove the support for OS X 10.6.

I want to add that I think it's theoretically possible to implement the 
TLS support code located in the dynamic linker in druntime. This would 
allow us to move to native TLS on OS X 10.7 while still supporting 10.6, 
with the same code.


 If so, is someone planning to switch it to OSX's thread locals?


I would guess that's the plan, eventually. It's basically a requirement 
for making dynamic libraries work. It's the same as with everything 
else, someone needs to commit time to make it happen.


 Jacob, it looks like you have been playing with D on Mac for awhile.


I certainly have :)



 I searched D forums for iOS or Mac stuff and your name comes up.  I think
 as a next step (pun intended) it would be cool to try something you have
 done to interface D with the objc world.  For now, I am just creating C
 functions as needed to glue objc messages to D.

 Also started playing some with the ObjC Runtime calls like

    objc_msgSend(obj, sel_registerName("release"))

 to do stuff like

    [obj release];

 That could go along way with some handy wrapper functions.  Then there
 is the project I think you mentioned to make D compiler directly support
 objc interfaces.


I just have started to work on the 64bit support for D/Objective-C [1] 
(same runtime as iOS).


 Would it be much work to fold it into the current compiler?


Unfortunately yes. The 32bit version is currently very usable. It 
basically only missing support for categories and blocks. For the 64bit 
version only the most basic functionally like: calling instance methods, 
class methods and implementing Objective-C classes on the D side. What's 
missing in the 64bit version is:

* Categories
* Protocols (interfaces)
* Catching exceptions (I have a workaround for this that I think is working)
* Properties
* All that's missing in the 32bit version

Non of the version supports ARC.

Except from all the missing features it would most likely require quite 
a lot of work to get the code approved and merged. There are quite a lot 
of changes in most of the phases in the compiler. Adding new syntax to 
the language is a high barrier.

If you want to use D/Objective-C you can DStep [2] to create bindings.


 Anyway, looking forward to any tools or thoughts you have.  For now,
 exception handling seems the most useful missing feature.  So I am
 looking at that.


[1] https://github.com/jacob-carlborg/dmd/tree/d-objc-64
[2] https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg
Feb 15 2014
prev sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
 For now, exception handling seems the most useful missing feature.  So
 I am looking at that.


I hacked in rudimentary SjLj exception handing code in the ldc/eh.d.  It
is kind of ugly, but it works on my D test cases (tried all of the
try/catch try/finally scope(exit) and friends, and RAII structs).  It
should also allow cleanup handlers when C++ exceptions (foreign ex)
bubble up, but haven't tested that yet.  Again, only testing on my
iPhone 4 (armv7).  I will push up changes ios-2.064 branch after I make
it less ugly.
-- 
Dan
Feb 16 2014
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
Dan Olson <zans.is.for.cans yahoo.com> writes:


 For now, exception handling seems the most useful missing feature.  So
 I am looking at that.


 I hacked in rudimentary SjLj exception handing code in the ldc/eh.d.  It
 is kind of ugly, but it works on my D test cases (tried all of the
 try/catch try/finally scope(exit) and friends, and RAII structs).  It
 should also allow cleanup handlers when C++ exceptions (foreign ex)
 bubble up, but haven't tested that yet.


Nevermind on allowing foreign (i.e. c++) exceptions for now.  When I let
a c++ exception bubble up through D stack, scope(success) triggers
instead of scope(failure).  I see why now.  scope(failure) is
essentially a catch(Throwable e) throw(t) which isn't selected.  It
would be cool to make it work, but not important, so I'll put it aside.
However, D being a system language, it _could_ have a mechanism for
catching non-D exceptions that escape from another language.

David, a question.  I read
https://github.com/ldc-developers/ldc/issues/489.

What is the symptom?  The iOS sjlj unwinder is different, but I'd like a
test case to see.

https://www.opensource.apple.com/source/libunwind/libunwind-35.1/src/Unwind-sjlj.c
-- 
Dan
Feb 17 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 17 Feb 2014, at 18:04, Dan Olson wrote:

 David, a question.  I read
 https://github.com/ldc-developers/ldc/issues/489.

 What is the symptom?  The iOS sjlj unwinder is different, but I'd like 
 a
 test case to see.


The ARM EABI (at least as far as the GCC runtime goes) doesn't use SLJL, 
but DWARF EH with a slightly different unwinding process.

I don't have reduced test cases for the remaining failures, 
unfortunately. It's just clear that EH is still not working correctly in 
all cases when running the Phobos test suite (you'll see crashes in 
_Unwind_RaiseException or related druntime abort()s).

David
Feb 17 2014
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"David Nadlinger" <code klickverbot.at> writes:


 On 17 Feb 2014, at 18:04, Dan Olson wrote:

 David, a question.  I read
 https://github.com/ldc-developers/ldc/issues/489.

 What is the symptom?  The iOS sjlj unwinder is different, but I'd
 like a
 test case to see.


 The ARM EABI (at least as far as the GCC runtime goes) doesn't use
 SLJL, but DWARF EH with a slightly different unwinding process.

 I don't have reduced test cases for the remaining failures,
 unfortunately. It's just clear that EH is still not working correctly
 in all cases when running the Phobos test suite (you'll see crashes in
 _Unwind_RaiseException or related druntime abort()s).


Hopefully when I run the phobos unittests in a day or two on iOS, can
see if I run into anything related.  When you say Phobos test suite, do
you just mean compiling phobos with -unittest and running all the
unittest blocks?

I don't know a way to run a bunch of little unittest programs on iOS, so
cooked up an approach that just bakes all unittests into one app.  Maybe
there are better ways, if someone with iOS dev experience has some
ideas, I'd like to know.

Recipe:
- Add -unittest to druntime library build flags. 

- Have main program iterate over ModuleInfo, calling unitTest func if
   set.

- Link with flag -force_load libdruntime-ldc-debug.a to pull every obj
   file into exe.

33 unittests ran and passed.  Two failed because they don't compile with
-unittest flag.  I will have to take an inventory because a simple grep
of druntime counts 38 files with 'unittest'.

thread.d fails to compile because I didn't finish fiber support for iOS,

and then this wierd one:

/Users/dan/projects/ldc/ldc-git/runtime/druntime/src/rt/aaA.d(565): Error:
Function type does not match previously declared function with the same mangled
name: _d_assocarrayliteralTX

-- 
Dan
Feb 18 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
On Tuesday, 18 February 2014 at 08:24:30 UTC, Dan Olson wrote:

 "David Nadlinger" <code klickverbot.at> writes:


 On 17 Feb 2014, at 18:04, Dan Olson wrote:

 David, a question.  I read
 https://github.com/ldc-developers/ldc/issues/489.

 What is the symptom?  The iOS sjlj unwinder is different, but 
 I'd
 like a
 test case to see.


 The ARM EABI (at least as far as the GCC runtime goes) doesn't 
 use
 SLJL, but DWARF EH with a slightly different unwinding process.

 I don't have reduced test cases for the remaining failures,
 unfortunately. It's just clear that EH is still not working 
 correctly
 in all cases when running the Phobos test suite (you'll see 
 crashes in
 _Unwind_RaiseException or related druntime abort()s).


 Hopefully when I run the phobos unittests in a day or two on 
 iOS, can
 see if I run into anything related.  When you say Phobos test 
 suite, do
 you just mean compiling phobos with -unittest and running all 
 the
 unittest blocks?

 I don't know a way to run a bunch of little unittest programs 
 on iOS, so
 cooked up an approach that just bakes all unittests into one 
 app.  Maybe
 there are better ways, if someone with iOS dev experience has 
 some
 ideas, I'd like to know.

 Recipe:
 - Add -unittest to druntime library build flags.

 - Have main program iterate over ModuleInfo, calling unitTest 
 func if
    set.

 - Link with flag -force_load libdruntime-ldc-debug.a to pull 
 every obj
    file into exe.

 33 unittests ran and passed.  Two failed because they don't 
 compile with
 -unittest flag.  I will have to take an inventory because a 
 simple grep
 of druntime counts 38 files with 'unittest'.

 thread.d fails to compile because I didn't finish fiber support 
 for iOS,

 and then this wierd one:

 /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/rt/aaA.d(565): 
 Error: Function type does not match previously declared 
 function with the same mangled name: _d_assocarrayliteralTX


This is one of the release blocking bugs. Please just ignore for 
now.

Regards,
Kai
Feb 26 2014
next sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Kai Nacke" <kai redstar.de> writes:


 On Tuesday, 18 February 2014 at 08:24:30 UTC, Dan Olson wrote:

 /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/rt/aaA.d(565):
 Error: Function type does not match previously declared function
 with the same mangled name: _d_assocarrayliteralTX


 This is one of the release blocking bugs. Please just ignore for now.

 Regards,
 Kai


Ok, thanks.  I have enough other unittest failures to keep me busy.
Many are floating point comparson related, I am guessing because of
cross compiling from x64 to arm.  Some are memory corruption, I think
due to gc not setup correctly.  They go away when I disable GC.  The
sjlj exception handling for arm/iOS is working, that is encouraging.

My iOS phobos/druntime unittest tally so far is:

67 pass
15 fail
5   not run (compiler error with -unittest option)
Feb 27 2014
parent reply "ElvisZhou" <elvis.x.zhou gmail.com> writes:
On Thursday, 27 February 2014 at 08:13:00 UTC, Dan Olson wrote:

 "Kai Nacke" <kai redstar.de> writes:


 On Tuesday, 18 February 2014 at 08:24:30 UTC, Dan Olson wrote:

 /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/rt/aaA.d(565):
 Error: Function type does not match previously declared 
 function
 with the same mangled name: _d_assocarrayliteralTX


 This is one of the release blocking bugs. Please just ignore 
 for now.

 Regards,
 Kai


 Ok, thanks.  I have enough other unittest failures to keep me 
 busy.
 Many are floating point comparson related, I am guessing 
 because of
 cross compiling from x64 to arm.  Some are memory corruption, I 
 think
 due to gc not setup correctly.  They go away when I disable GC.
  The
 sjlj exception handling for arm/iOS is working, that is 
 encouraging.

 My iOS phobos/druntime unittest tally so far is:

 67 pass
 15 fail
 5   not run (compiler error with -unittest option)


This is really encouraging, I really appreciate every effort 
you've made!
Feb 27 2014
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 27 February 2014 at 13:16:25 UTC, ElvisZhou wrote:

 On Thursday, 27 February 2014 at 08:13:00 UTC, Dan Olson wrote:

 "Kai Nacke" <kai redstar.de> writes:


 On Tuesday, 18 February 2014 at 08:24:30 UTC, Dan Olson wrote:

 /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/rt/aaA.d(565):
 Error: Function type does not match previously declared 
 function
 with the same mangled name: _d_assocarrayliteralTX


 This is one of the release blocking bugs. Please just ignore 
 for now.

 Regards,
 Kai


 Ok, thanks.  I have enough other unittest failures to keep me 
 busy.
 Many are floating point comparson related, I am guessing 
 because of
 cross compiling from x64 to arm.  Some are memory corruption, 
 I think
 due to gc not setup correctly.  They go away when I disable GC.
 The
 sjlj exception handling for arm/iOS is working, that is 
 encouraging.

 My iOS phobos/druntime unittest tally so far is:

 67 pass
 15 fail
 5   not run (compiler error with -unittest option)


 This is really encouraging, I really appreciate every effort 
 you've made!


+1 !

I always get goosebumps when this thread shows unread posts ;)
Feb 27 2014
parent Dan Olson <zans.is.for.cans yahoo.com> writes:
"Szymon Gatner" <noemail gmail.com> writes:


 On Thursday, 27 February 2014 at 13:16:25 UTC, ElvisZhou wrote:

 On Thursday, 27 February 2014 at 08:13:00 UTC, Dan Olson wrote:

 "Kai Nacke" <kai redstar.de> writes:


 On Tuesday, 18 February 2014 at 08:24:30 UTC, Dan Olson wrote:

 /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/rt/aaA.d(565):
 Error: Function type does not match previously declared function
 with the same mangled name: _d_assocarrayliteralTX


 This is one of the release blocking bugs. Please just ignore for
 now.

 Regards,
 Kai


 Ok, thanks.  I have enough other unittest failures to keep me busy.
 Many are floating point comparson related, I am guessing because of
 cross compiling from x64 to arm.  Some are memory corruption, I
 think
 due to gc not setup correctly.  They go away when I disable GC.
 The
 sjlj exception handling for arm/iOS is working, that is
 encouraging.

 My iOS phobos/druntime unittest tally so far is:

 67 pass
 15 fail
 5   not run (compiler error with -unittest option)


 This is really encouraging, I really appreciate every effort you've
 made!


 +1 !

 I always get goosebumps when this thread shows unread posts ;)


Nice to know!  Funny thing is the main reason I started on this was a
lack of snow in the mountains (I like snowboarding), so I had some
"free" time waiting for ski areas to open.  Now that this iOS project is
started, it is easier to pick it back up for an hour here and there.
-- 
Dan
Feb 28 2014
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On 26 Feb 2014, at 19:11, Kai Nacke wrote:

 On Tuesday, 18 February 2014 at 08:24:30 UTC, Dan Olson wrote:

 /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/rt/aaA.d(565): 
 Error: Function type does not match previously declared function with 
 the same mangled name: _d_assocarrayliteralTX


 This is one of the release blocking bugs. Please just ignore for now.


It's obviously your choice, but I'm not sure whether this should 
actually be a release-blocking bug or if it would make more sense to 
just comment out that unit test (IIRC there are some commented out 
already) and ignore the mismatch until we start work on full-LTO builds.

David
Feb 27 2014