ObjC Interoperability under armv7--linux-gnueabi

linux

(Iliya Trub) #1

Dear colleagues
Ihave built swiftc, libswiftCore.so and other outputs under armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. I linked the simplest swift-application, which creates the instance of custom ObjC-class and call instance-method of it. If somebody interested, I am ready to provide patches, though I know that it can not be included into upstream. But there is not success yet. When I try to run application under armv7l-linux, I get following error:

Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass
NSArray. Offset of first instance variable, __magic_refCount, is 4.
Last instance variable in superclass, _sortedArrayHint, ends at offset
8. This probably means that you are subclassing aclass from a library,
which has changed in a binary-incompatibleway.

Could anybody explain it? I think, it is explained by some difference between NSArray-implementation in XCode framework and in my opensource library. Is it true? And in what way I can try to fix it? May be, to modify my NSArray-source, but how?
Thanks in advance for answer.


(Philippe Hausler) #2

I would guess that you are emitting with the wrong runtime personality (iirc linux defaults to fragile (objc1) GNU objc runtime). You might need to muck about with flags, most notably -fobjc-runtime. That being said that path might be filled with other issues beyond just the layout differentials. There are many potential failure points along the way that would have to be dealt with.

···

On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev <swift-dev@swift.org> wrote:

Dear colleagues
Ihave built swiftc, libswiftCore.so and other outputs under armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. I linked the simplest swift-application, which creates the instance of custom ObjC-class and call instance-method of it. If somebody interested, I am ready to provide patches, though I know that it can not be included into upstream. But there is not success yet. When I try to run application under armv7l-linux, I get following error:

Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass
NSArray. Offset of first instance variable, __magic_refCount, is 4.
Last instance variable in superclass, _sortedArrayHint, ends at offset
8. This probably means that you are subclassing aclass from a library,
which has changed in a binary-incompatibleway.

Could anybody explain it? I think, it is explained by some difference between NSArray-implementation in XCode framework and in my opensource library. Is it true? And in what way I can try to fix it? May be, to modify my NSArray-source, but how?
Thanks in advance for answer.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Daniel DeCovnick) #3

I’d be interested in the patches.

Daniel

···

On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev <swift-dev@swift.org> wrote:

Dear colleagues
Ihave built swiftc, libswiftCore.so and other outputs under armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. I linked the simplest swift-application, which creates the instance of custom ObjC-class and call instance-method of it. If somebody interested, I am ready to provide patches, though I know that it can not be included into upstream. But there is not success yet. When I try to run application under armv7l-linux, I get following error:

Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass
NSArray. Offset of first instance variable, __magic_refCount, is 4.
Last instance variable in superclass, _sortedArrayHint, ends at offset
8. This probably means that you are subclassing aclass from a library,
which has changed in a binary-incompatibleway.

Could anybody explain it? I think, it is explained by some difference between NSArray-implementation in XCode framework and in my opensource library. Is it true? And in what way I can try to fix it? May be, to modify my NSArray-source, but how?
Thanks in advance for answer.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Joe Groff) #4

The implementation of our ObjC interop makes pretty deep invasive assumptions about the Apple ObjC runtime ABI as well as the implementation of classes in Cocoa. It probably needs to be rewritten from the ground up to support another runtime and Foundation implementation.

-Joe

···

On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev <swift-dev@swift.org> wrote:

Dear colleagues
Ihave built swiftc, libswiftCore.so and other outputs under armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. I linked the simplest swift-application, which creates the instance of custom ObjC-class and call instance-method of it. If somebody interested, I am ready to provide patches, though I know that it can not be included into upstream. But there is not success yet. When I try to run application under armv7l-linux, I get following error:

Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass
NSArray. Offset of first instance variable, __magic_refCount, is 4.
Last instance variable in superclass, _sortedArrayHint, ends at offset
8. This probably means that you are subclassing aclass from a library,
which has changed in a binary-incompatibleway.

Could anybody explain it? I think, it is explained by some difference between NSArray-implementation in XCode framework and in my opensource library. Is it true? And in what way I can try to fix it? May be, to modify my NSArray-source, but how?
Thanks in advance for answer.


(Iliya Trub) #5

I emitted with -fobjc-runtime=gnustep.

···

29.03.2016, 23:13, "Philippe Hausler" <phausler@apple.com>:

I would guess that you are emitting with the wrong runtime personality (iirc linux defaults to fragile (objc1) GNU objc runtime). You might need to muck about with flags, most notably -fobjc-runtime. That being said that path might be filled with other issues beyond just the layout differentials. There are many potential failure points along the way that would have to be dealt with.

�On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev <swift-dev@swift.org> wrote:

�Dear colleagues
�Ihave built swiftc, libswiftCore.so and other outputs under armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. I linked the simplest swift-application, which creates the instance of custom ObjC-class and call instance-method of it. If somebody interested, I am ready to provide patches, though I know that it can not be included into upstream. But there is not success yet. When I try to run application under armv7l-linux, I get following error:

�Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass
�NSArray. Offset of first instance variable, __magic_refCount, is 4.
�Last instance variable in superclass, _sortedArrayHint, ends at offset
�8. This probably means that you are subclassing aclass from a library,
�which has changed in a binary-incompatibleway.

�Could anybody explain it? I think, it is explained by some difference between NSArray-implementation in XCode framework and in my opensource library. Is it true? And in what way I can try to fix it? May be, to modify my NSArray-source, but how?
�Thanks in advance for answer.
�_______________________________________________
�swift-dev mailing list
�swift-dev@swift.org
�https://lists.swift.org/mailman/listinfo/swift-dev

--�
� ���������,
���� ����
+79032407864


(Iliya Trub) #6

The implementation of our ObjC interop makes pretty deep invasive assumptions about the Apple ObjC runtime ABI as well as the implementation of classes in Cocoa. It probably needs to be rewritten from the ground up to support another runtime and Foundation implementation.

-Joe

Alas, I agree. I think just that too. Thanks.

···

30.03.2016, 01:22, "Joe Groff" <jgroff@apple.com>:

�On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev <swift-dev@swift.org> wrote:

�Dear colleagues
�Ihave built swiftc, libswiftCore.so and other outputs under armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. I linked the simplest swift-application, which creates the instance of custom ObjC-class and call instance-method of it. If somebody interested, I am ready to provide patches, though I know that it can not be included into upstream. But there is not success yet. When I try to run application under armv7l-linux, I get following error:

�Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass
�NSArray. Offset of first instance variable, __magic_refCount, is 4.
�Last instance variable in superclass, _sortedArrayHint, ends at offset
�8. This probably means that you are subclassing aclass from a library,
�which has changed in a binary-incompatibleway.

�Could anybody explain it? I think, it is explained by some difference between NSArray-implementation in XCode framework and in my opensource library. Is it true? And in what way I can try to fix it? May be, to modify my NSArray-source, but how?
�Thanks in advance for answer.

The implementation of our ObjC interop makes pretty deep invasive assumptions about the Apple ObjC runtime ABI as well as the implementation of classes in Cocoa. It probably needs to be rewritten from the ground up to support another runtime and Foundation implementation.

-Joe

--�
� ���������,
���� ����
+79032407864


(Iliya Trub) #7

I'd like to add, that I have overcomed "subject"error in very simple path. I indeed forgot to add -fobjc-runtime=gnustep to all needed places. THIS error disappeared, but the new error appeared:

main2: dwarf/Gparser.c:456: fetch_proc_info: Assertion
`c->pi.unwind_info' failed

Any opinions? I even do not know, from what library Gparser.c is.
So, sucess story with launch of the simplest application is not reached.

···

30.03.2016, 01:22, "Joe Groff" <jgroff@apple.com>:

�On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev <swift-dev@swift.org> wrote:

�Dear colleagues
�Ihave built swiftc, libswiftCore.so and other outputs under armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. I linked the simplest swift-application, which creates the instance of custom ObjC-class and call instance-method of it. If somebody interested, I am ready to provide patches, though I know that it can not be included into upstream. But there is not success yet. When I try to run application under armv7l-linux, I get following error:

�Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass
�NSArray. Offset of first instance variable, __magic_refCount, is 4.
�Last instance variable in superclass, _sortedArrayHint, ends at offset
�8. This probably means that you are subclassing aclass from a library,
�which has changed in a binary-incompatibleway.

�Could anybody explain it? I think, it is explained by some difference between NSArray-implementation in XCode framework and in my opensource library. Is it true? And in what way I can try to fix it? May be, to modify my NSArray-source, but how?
�Thanks in advance for answer.

The implementation of our ObjC interop makes pretty deep invasive assumptions about the Apple ObjC runtime ABI as well as the implementation of classes in Cocoa. It probably needs to be rewritten from the ground up to support another runtime and Foundation implementation.

-Joe

--�
� ���������,
���� ����
+79032407864


(Joe Groff) #8

It's highly unlikely that the Gnustep runtime will be able to make any sense of the class metadata we emit, or that the assumptions we make about NSObject, NSString, etc. are valid for Gnustep's implementations, so you're in undefined behavior territory.

-Joe

···

On Mar 30, 2016, at 3:27 AM, Iliya Trub <itrub@yandex.ru> wrote:

I'd like to add, that I have overcomed "subject"error in very simple path. I indeed forgot to add -fobjc-runtime=gnustep to all needed places. THIS error disappeared, but the new error appeared:

main2: dwarf/Gparser.c:456: fetch_proc_info: Assertion
`c->pi.unwind_info' failed

Any opinions? I even do not know, from what library Gparser.c is.
So, sucess story with launch of the simplest application is not reached.


(Iliya Trub) #9

Of course, I fully understand, that project is most likely hopeless. But for now I have some time to try.

···

30.03.2016, 20:34, "Joe Groff" <jgroff@apple.com>:

�On Mar 30, 2016, at 3:27 AM, Iliya Trub <itrub@yandex.ru> wrote:

�I'd like to add, that I have overcomed "subject"error in very simple path. I indeed forgot to add -fobjc-runtime=gnustep to all needed places. THIS error disappeared, but the new error appeared:

�main2: dwarf/Gparser.c:456: fetch_proc_info: Assertion
�`c->pi.unwind_info' failed

�Any opinions? I even do not know, from what library Gparser.c is.
�So, sucess story with launch of the simplest application is not reached.

It's highly unlikely that the Gnustep runtime will be able to make any sense of the class metadata we emit, or that the assumptions we make about NSObject, NSString, etc. are valid for Gnustep's implementations, so you're in undefined behavior territory.

-Joe

--�
� ���������,
���� ����
+79032407864


(Luke Howard) #10

As I think I mentioned before, you’ll probably have more luck porting the Apple runtime [1] to Linux than getting it to work with the GNUstep runtime.

— Luke

[1] http://opensource.apple.com/source/objc4/objc4-680/

···

On 31 Mar 2016, at 6:02 AM, Iliya Trub via swift-dev <swift-dev@swift.org> wrote:

Of course, I fully understand, that project is most likely hopeless. But for now I have some time to try.

30.03.2016, 20:34, "Joe Groff" <jgroff@apple.com>:

On Mar 30, 2016, at 3:27 AM, Iliya Trub <itrub@yandex.ru> wrote:

I'd like to add, that I have overcomed "subject"error in very simple path. I indeed forgot to add -fobjc-runtime=gnustep to all needed places. THIS error disappeared, but the new error appeared:

main2: dwarf/Gparser.c:456: fetch_proc_info: Assertion
`c->pi.unwind_info' failed

Any opinions? I even do not know, from what library Gparser.c is.
So, sucess story with launch of the simplest application is not reached.

It's highly unlikely that the Gnustep runtime will be able to make any sense of the class metadata we emit, or that the assumptions we make about NSObject, NSString, etc. are valid for Gnustep's implementations, so you're in undefined behavior territory.

-Joe

--
С уважением,
Труб Илья
+79032407864
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
www.lukehoward.com
soundcloud.com/lukehoward