> On 11 Jan 2019, at 23:47, Sergii Stoian <[email protected]> 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 mkdir gnustep cd gnustep wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.15.tar.gz git clone https://github.com/apple/swift-corelibs-libdispatch git clone https://github.com/gnustep/scripts git clone https://github.com/gnustep/make git clone https://github.com/gnustep/libobjc2 git clone https://github.com/gnustep/base git clone https://github.com/gnustep/corebase git clone https://github.com/gnustep/gui git clone https://github.com/gnustep/back ./scripts/install-dependencies 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 <[email protected] > <mailto:[email protected]>> 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/ <http://apt.llvm.org/stretch/> > llvm-toolchain-stretch-7 main > deb-src http://apt.llvm.org/stretch/ <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. > [[email protected] <mailto:[email protected]> 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 > <http://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 > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > <https://lists.gnu.org/mailman/listinfo/discuss-gnustep> > > > -- > Sergii Stoian, > ProjectCenter lead developer > NEXTSPACE owner, lead developer
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
