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.
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
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
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.
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
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.
�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.
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:
�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.
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:
�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:
�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.
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:
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.