discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUStep runtime / libobjc2 build problems: tests failing or segfault


From: Andreas Fink
Subject: Re: GNUStep runtime / libobjc2 build problems: tests failing or segfaulting
Date: Wed, 16 Jan 2019 11:40:37 +0100



On 11 Jan 2019, at 23:47, Sergii Stoian <stoyan255@gmail.com> wrote:

Hi Andreas,

I've played a little with new release and I guess I know what the cause of a problem. Sometimes gnustep-make adds `-fobjc-runtime=gcc` to the ObjC compiler options.
Check your config.log if test compiles with this flag.



Hello Sergjii

The config.log only contains -fobjc-runtime=gnustep-2.0

I did reproduce this today with a freshly installed VM.
Here is how I did it.
I have llvm from this repo

deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-7 main
deb-src http://apt.llvm.org/stretch/ llvm-toolchain-stretch-7 main
deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch main
deb-src http://apt.llvm.org/stretch/ llvm-toolchain-stretch main

I also have the backport repo added. And installed a base system with no gui.

and did install this way

apt-get purge libblocksruntime-dev libblocksruntime0
apt-get install clang-8 lldb-8 llvm-8 libc++-8-dev lld-8 python-lldb-8 base-essential git subversion automake autoconf pkgconfig libtool

pushd /usr/bin
rm -f clang clang++ clang-cpp lldb
ln -s clang-8 clang
ln -s clang++-8 clang++
ln -s clang-cpp-8 clang-cpp
ln -s lldb-8 lldb
popd


export CC=/usr/bin/clang-8
export CXX=/usr/bin/clang++-8
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
export RUNTIME_VERSION=gnustep-2.0



tar -xvzf libiconv-1.15.tar.gz
cd libiconv-1.15
./configure
make
make install
cd ..

cd swift-corelibs-libdispatch
mkdir build
cd build
cmake .. -DCMAKE_C_COMPILER=${CC} -DCMAKE_CXX_COMPILER=${CXX} -DCMAKE_BUILD_TYPE=RelWithDebInfo
make
make install



cd make
export OBJCFLAGS="-fblocks"
export LDLAGS="-L/usr/local/lib"
./configure \
--with-layout=fhs \
--disable-importing-config-file \
--enable-native-objc-exceptions \
--enable-objc-arc \
--enable-install-ld-so-conf \
--with-library-combo=ng-gnu-gnu \
--with-config-file=/usr/local/etc/GNUstep/GNUstep.conf \
--with-user-config-file='.GNUstep.conf' \
--with-user-defaults-dir='GNUstep/Library/Defaults' \
--with-objc-lib-flag="-l:libobjc.so.4.6"
make install
source /usr/local/etc/GNUstep/GNUstep.conf
cd ..

cd libobjc2
mkdir Build
cd Build
cmake ..  -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_STATIC_LIBOBJC=1  -DCMAKE_C_COMPILER=${CC} -DCMAKE_CXX_COMPILER=${CXX} -DTESTS=OFF 
make -j8
make install
cd ..
ldconfig



cd base
./configure  --with-config-file=/usr/local/etc/GNUstep/GNUstep.conf  
make -j8
make install
cd ../..
ldconfig


after this,  I run make check and it results in

    343 Failed files
      8 Passed tests


The constant strings error messages are however gone now.
I had massive problems with memory in libobjc2 release 1.9. It seems a lot of objects are
not freeing memory in my system in some cases even though they are properly deallocated

I did not see any reference to the gcc objc library and its not even installed.

I can give access to that system if needed. I only created this VM for testing this specific case.




On Tue, Dec 18, 2018 at 9:31 AM Andreas Fink <afink@list.fink.org> wrote:
Hi all,

I'm trying to build gnustep base  with clang-7 on debian 9 and I constantly run into incompatibilities from the runtime or tests failing and I can't figure out the dependency issues here.


clang-7 comes from the clang repository

deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-7 main
deb-src http://apt.llvm.org/stretch/ llvm-toolchain-stretch-7 main


My gnustep make is configured like this:


export CC=/usr/bin/clang-7
export CXX=/usr/bin/clang++-7
export LD=/usr/bin/lld-7
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
export RUNTIME_VERSION=gnustep-1.9
export OBJCFLAGS="-fblocks"
export CFLAGS="-L/usr/local/lib"
./configure \
            --with-layout=fhs \
            --disable-importing-config-file \
            --enable-native-objc-exceptions \
            --enable-objc-arc \
            --enable-install-ld-so-conf \
            --with-library-combo=ng-gnu-gnu \
            --with-config-file=/usr/local/etc/GNUstep/GNUstep.conf \
            --with-user-config-file='.GNUstep.conf' \
            --with-user-defaults-dir='GNUstep/Library/Defaults' \
            --with-objc-lib-flag="-l:libobjc.so.4.6" \


my libobjc2 is compiled like this:

    cmake .. -DCMAKE_C_COMPILER=/usr/bin/clang-7 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-7  -DCMAKE_LINKER=/usr/bin/lld-7 -DCMAKE_BUILD_TYPE=RelWithDebInfo


and then when I compile gnustep-base

    export RUNTIME_VERSION=gnustep-1.9
    export OBJCFLAGS="-fblocks"
    export CFLAGS="-L/usr/local/lib"
    ./configure \
            --with-layout=fhs \
            --disable-importing-config-file \
            --enable-native-objc-exceptions \
            --enable-objc-arc \
            --enable-install-ld-so-conf \
            --with-library-combo=ng-gnu-gnu \
            --with-config-file=/usr/local/etc/GNUstep/GNUstep.conf \
            --with-user-config-file='.GNUstep.conf' \
            --with-user-defaults-dir='GNUstep/Library/Defaults' \
            --with-objc-lib-flag="-l:libobjc.so.4.6" \



I get this:

configure: error: Your compiler does not appear to implement the -fconstant-string-class option needed for support of strings.  Please check for a more recent version or consider using --enable-nxconstantstring

well clang-7 definitively does know -fconstant-string so this test is going nuts somehow.


I looked at the test  config/config.constant-string-class.m
and I figured out it segfaults:


# clang-7 -O0 -g config/config.constant-string-class.m -l:libobjc.so.4.6
In file included from config/config.constant-string-class.m:19:
config/objc-common.g:54:3: warning: assignment to Objective-C's isa is deprecated in favor of object_setClass() [-Wdeprecated-objc-isa-usage]
  obj->isa = self;
  ^  ~~~~~~~
  object_setClass( , )
config/objc-common.g:47:5: note: instance variable is declared here
 id isa;
    ^
config/objc-common.g:45:31: warning: class 'NSObject' defined without specifying a base class [-Wobjc-root-class]
GS_OBJC_ROOT_CLASS @interface NSObject
                              ^
config/objc-common.g:45:39: note: add a super class to fix this problem
GS_OBJC_ROOT_CLASS @interface NSObject
                                      ^
                                       : NSObject
config/config.constant-string-class.m:23:31: warning: class 'FooConstantString' defined without specifying a base class [-Wobjc-root-class]
GS_OBJC_ROOT_CLASS @interface FooConstantString
                              ^
config/config.constant-string-class.m:23:48: note: add a super class to fix this problem
GS_OBJC_ROOT_CLASS @interface FooConstantString
                                               ^
                                                : NSObject
config/config.constant-string-class.m:49:23: warning: incompatible pointer types initializing 'FooConstantString *' with an _expression_ of type 'NSString *'
      [-Wincompatible-pointer-types]
   FooConstantString *string = @"Antonio Valente";
                      ^        ~~~~~~~~~~~~~~~~~~
4 warnings generated.
[root@gnustep.fink-telecom.com base]# lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) run
Process 15116 launched: '/Users/afink/development/gnustep/base/a.out' (x86_64)
Process 15116 stopped
* thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x00007ffff7bcaae8 libobjc.so.4`___lldb_unnamed_symbol45$$libobjc.so.4 + 72
libobjc.so.4`___lldb_unnamed_symbol45$$libobjc.so.4:
->  0x7ffff7bcaae8 <+72>: movq   (%r12), %rax
    0x7ffff7bcaaec <+76>: movl   %eax, %ecx
    0x7ffff7bcaaee <+78>: movq   %rax, %rdx
    0x7ffff7bcaaf1 <+81>: shll   $0x5, %ecx
(lldb)



if I patch out the constant string test in configure.ac and rebuild it, then most gnustep-base test cases fail.

So I'm kind of lost on where the heck this comes from. I noticed in the past that my classes get referred to the wrong runtime version and thus access to members of superclasses returned wrong values which apparently depends on runtime version which is the reason why I want to recompile everything with a specific runtime version so we have 100% sure everything uses the same ABI. I only run my own code so I dont' need backwards compatibility.

Does anyone have a clue on how to fix this?



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep


--
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer


reply via email to

[Prev in Thread] Current Thread [Next in Thread]