On 05/06/2019 05:30, Riccardo Mottola wrote:
Hi,
David Chisnall wrote:
On 04/06/2019 09:46, Riccardo Mottola wrote:
Hi David,
David Chisnall wrote:
Thanks for the report. Please can you file an issue on GitHub? This
is a quite surprising error - it implies that either clang has a bug
or that something is trying to manually create or modify protocols
without calling through the runtime. This might happen if you have
a version of GNUstep compiled against the gcc runtime and using
ObjectiveC2.framework instead of the runtime's public APIs, but that
shouldn't be the case with the packaged versions.
clang and libobjc2 are packaged, however gnustep installation is
compiled by my by current sources. I did not do anything special, I
configured make with:
$ ./configure --prefix=/ --with-layout=gnustep
CFLAGS=-I/usr/local/include
Are you using -make from packages, which will be configured to use the
new ABI?
no, I am using everyghing from git HEAD of our repositories, including
latest gnustep make.
Do you pass some special configuration parameters when packaging? I can
attempt that.
All of the configuration parameters that I use for the packages are in
the port Makefile(s). I do build everything with the ng library combo
though.
Okay, this is not one that will be used by -make from packages,
because it doesn't support the 2.0 ABI. Please use the clang from the
llvm7 or lllv8 package, or from the base system in 12. It looks as if
you're using the old (GCC) ABI, which may mean that you've linked in
the ObjectiveC2 framework and are explicitly constructing internal
runtime data structures from an old version of the runtime. Please
can you check where the invalid protocol is coming from? It may also
be something that we're failing to correctly upgrade when using the
legacy ABI.
Ok, so it is an older compiler, but should not the runtime support it?
there are no two libobjc2 packages, or is libobjc2 no longer compatible
with the GCC runtime?
How can I check for the protocol? It is coming "from inside GNUstep"
since I just installed core packages and then am running Ink, so there
is no custom code of mine.
Maybe we just have some issue in gnustep which we didn't discover.
Can you do a backtrace of where the crash is? What is the protocol that
it's inspecting while crashing?
When you say "upgrade" are you referring to FreeBSD package upgrade or
GNUstep ?
The 2.x runtime series uses a new set of internal structures. It
transparently upgrades all old runtime structures to the new layout
(there may be places where this fails, if so they are bugs - please
report them with test cases in the GitHub issue tracker). The runtime
has not for a long time supported external code generating these
structures, as the ObjectiveC2 framework does when used with an old
runtime, and provides public APIs for creating and modifying them so
that they can be opaque to user code. With the 1.x series, this all
probably mostly worked, because things were upgraded lazily where
necessary, not on load. That complicated the runtime internals a lot
and the 2.x series is a lot cleaner, but will definitely break if used
with code that expects to poke runtime data structures and expects them
to have the GCC runtime layouts.
Indeed, on another computer where I am running FreeBSD 12 instead,
everything worked out of the box.
Hopefully that's picking up the 8.x compiler and everything is the new ABI.
David
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
