How to make GNUstep libobjc2 to work? - objective-c

I downloaded and built GNUstep libobjc2 1.6.1,
svn co http://svn.gna.org/svn/gnustep/libs/libobjc2/1.6.1/ rep
cd rep
make
and got this error when I tried to compile a Objective-C code.
hoon#ubuntu:~/work/objc2$ clang -fobjc-nonfragile-abi -fobjc-arc -fblocks *.m *.a -l pthread; ./a.out
Objective-C ABI Error: Loading modules from incompatible ABIs while loading
a.out: loader.c:38: __objc_exec_class: Assertion `objc_check_abi_version(module)' failed.
Aborted (core dumped)
It seems I need to build libobjc.a with some different configurations. What is the problem and what should I do to fix this error?
Env: Ubuntu 12.04 LTS

This is a good question because LLVM and CLang and GNUstep don't claim to be hard or complicated to use. They do ask their users to read (and reread) their documentation though. I've just discovered this combination for Ubuntu myself and it is very intriguing. And there are a lot of moving parts at the moment.
If the OP got an answer on one of the gnustep mailing lists, then it would be nice to hear here how it was resolved.
Without suggesting the normal route of starting over and only installing the latest from LLVM and GNUstep directly, here's my take.
The OP is trying to use ARC and blocks with the runtime provided by the gunstep/libobjc2 project.
libobjc2 should probably be built with clang version 3.2 - or maybe the top of tree.
clang -v will tell you what version you have on your machine. I've found even Ubuntu 12.10 doesn't provide clang-3.2. So I download it from the LLVM website. They have prebuilt binaries for Ubuntu 12.04 LTS. To get make to use clang for this build step, I've seen instructions to set and export CC=clang and CXX=clang++.
Once libobjc2 is built, care must be taken where it gets installed. If the system already has an older libobjc.so.x.y library (this provides the runtime environment for Obj-C), clang or the linker may be picking up the wrong one when you start compiling your own source. I found libobjc.so.4.6.0 built from the libobjc2 source was installed to /usr/local/lib both on Ubuntu 12.04 and 12.10 when I ran the make install step. This path was not setup by the libobjc2 install step.
To get this library picked up, I had to add /usr/local/lib to the env variable LD_LIBRARY_PATH. It wouldn't hurt to try 'locate libojbc.so' to see if there are other versions on the system.
Finally, the libobjc2 readme, https://github.com/gnustep/gnustep-libobjc2#readme, says this new version of the gnustep library supports two ABIs, and each ABI supports ARC and blocks. The advice I've seen about compiling with libobjc2 is to also provide the runtime version expected to be compiling and linking with: -fobjc-runtime=gnustep. Clang on Ubuntu still defaults to the older ABI. -fobjc-nonfragile-abi may accomplish the same thing but I've seen it mentioned that flag was or will be deprecated.
The OP error may actually come from the step where a.out is being run, rather than where clang was compiled. Perhaps the dynamic loader is picking up the legacy libobj.so. Again, I would use locate to see if the system even has more than one.

This is just a guess, but I'm gonna go out on a limb and guess that GNUstep is going to build with GCC by default. A good first step might be to reconfigure the GNUstep build to use Clang. I can't say what variety of issues that will expose, but...
Alternately, you could try building your application with GCC instead of Clang.

This is a fairly late answer, but I have found a way to get everything working (on Elementary OS specifically so I imagine it should be fine on Ubuntu and similar distros).
As mentioned, it is better/easier to build everything from source because you get to pick the prefix, build options, etc. The general method:
Install cmake (if it's not already installed) --> sudo apt-get install cmake
Download, build and install llvm and clang as per the instructions here (or see attached build script). For speed, use the --enable-optimized flag. Tests are "optional" ;-)
The default build scripts for compiler-rt do not include the Blocks runtime. You could modify the build scripts, or rejoice that someone else has already done it (particularly if, like me, your cmake isn't great). Download, build and install libBlocksRuntime from this git repo (it is essentially a clone of the latest compiler-rt Blocks runtime code with custom build scripts). FOLLOW THEIR COMPILATION AND TESTING METHOD.
Download, build and install libobjc2 from GNUStep. The instructions for correct building are actually inside the now-deprecated makefile.
Run ldconfig (if required - though there's no harm in running it even if it isn't).
As #WeakPointer you may still need to edit the LD_LIBRARY_PATH environment variable to pick up your new libraries. Another option is to make some quick and dirty symlinks so clang can find your new libraries.
Final note: I haven't done any comparisons between GNUStep's libobjc2 and GCC's libobjc, the latter of which DOES contain some Objective-C 2.0 features... Be careful with your library selection if you keep both on your system at the same time!
The following script should do it all (untested!):
#!/bin/bash
# Temporary base directories
basedir="./clangllvm_temp"
basedir2="./libBlocksRuntime_temp"
basedir3="./libObjc2_temp"
# Clang, llvm, compiler-rt
mkdir $basedir
cd $basedir
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
cd ../..
cd llvm/tools/clang/tools
svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra
cd ../../../..
cd llvm/projects
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
cd ../..
mkdir build
cd build
../llvm/configure --prefix=$PREFIX --enable-optimized
make
sudo make install
cd ../..
# libBlocksRuntime
git clone https://github.com/mackyle/blocksruntime.git $basedir2
cd $basedir2
sudo ./buildlib
sudo ./checktests
sudo ./installlib
# Test!
clang -o sample -fblocks sample.c -lBlocksRuntime && ./sample
cd ..
# libobjc2
https://github.com/gnustep/gnustep-libobjc2.git $basedir3
cd $basedir3
mkdir Build
cd Build
cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
sudo make && sudo -E make install
cd ../..
# Cleanup
rm -rf $basedir
rm -rf $basedir2
rm -rf $basedir3
# ldconfig
sudo ldconfig
# Additional symlink/LD_LIBRARY_PATH stuff here if required.
# EOF

Key difference was using Clang for build. Take care not to use GCC which is system default compiler. I removed gobjc and g++ packages from system to avoid this issue.
export CC=clang
export CXX=clang++
svn co http://svn.gna.org/svn/gnustep/libs/libobjc2/1.6.1/
cd 1.6.1
make
This answer was hinted from this mailing list thread:
http://lists.gnu.org/archive/html/discuss-gnustep/2012-12/msg00036.html
Described script is posted here:
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
Now it compiles simple ARC code.
It seems GCC and Clang generated codes are incompatible.
Update
I wrote scripts to setup libobjc2 on FreeBSD and CentOS.
The scripts are mostly copied from a blog.

Related

gst-browser fails to start

I have just installed gst-browser (VisualGST) through the Canonical Ubuntu repositories, so I tried to start VisualGST by running gst-browser on the command line. However, I am immediately greeted with an error:
a Smalltalk Stream:2: Abandon
a Smalltalk Stream:2: Error occurred while not in byte code interpreter!!
/usr/lib/libgst.so.7(+0x74c97)[0x7fb5fa5d1c97]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7fb5fa1aaf20]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fb5fa1aae97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fb5fa1ac801]
/usr/lib/libgst.so.7(+0x2c6a6)[0x7fb5fa5896a6]
/usr/lib/x86_64-linux-gnu/libsigsegv.so.2(+0xe3c)[0x7fb5f9f68e3c]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7fb5fa1aaf20]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_type_check_is_value_type+0x23)[0x7fb5d4e374f3]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x20785e)[0x7fb5d551185e]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_list_store_new+0xa4)[0x7fb5d5436d94]
[1] 14556 abort (core dumped) gst-browser
What is the cause and meaning of the error, and how can I start VisualGST properly?
GNU Smalltalk version: 3.2.5
EDIT:
This appears to be a known issue. There's a bug report from 2012 on Launchpad: Smalltalk browser does not launch.
This appears to to be "known" issue. As I previously guessed the issue was in libraries link(age).
You can solve your issue either by installing - libgtk2.0-dev.
You can find the whole conversation here. Here is an excerpt:
Digging a bit further, I found that the module "gst-gtk-3.2.92.so" is
linked against "libgtk-x11-2.0.so", which is (now?) only provided by
package: gtk2-devel.
Your second option is to compile it from source. On Fedora 27 (again from the discussion and link above):
I'm on Fedora 27 and after a fresh install this gave me a working build:
sudo dnf install gcc git automake bison flex libtool libtool-ltdl-devel libffi-devel libsigsegv-devel cairo-devel gtk2-devel texinfo
git clone git://git.sv.gnu.org/smalltalk.git
cd smalltalk
autoreconf -vi ./configure make
sudo make install
-----------------------
For future referece you can find testing gst-browser gist.

installation of cmake on debian 8

I tried to install mcsema on my debian linux but I am stopped by error
Cmake 3.1 or higher is required. You are running 3.0.2. On debian this is the only version could be installed by apt-get install. Building CMake from sources, I get several errors as well. Does anyone know how to install the latest version of Cmake on Debian 8?
Download latests cmake release and follow the README.rst instructions:
UNIX/Mac OSX/MinGW/MSYS/Cygwin ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You need to have a compiler and a make installed. Run the
bootstrap script you find in the source directory of CMake. You
can use the --help option to see the supported options. You may
use the --prefix=<install_prefix> option to specify a custom
installation directory for CMake. You can run the bootstrap script
from within the CMake source directory or any other build directory of
your choice. Once this has finished successfully, run make and
make install. In summary::
$ ./bootstrap && make && make install

How to install and use libnet in mac os?

I want to program in C with libnet in Mac OS.
When I type in gcc *.o -o network -lnet, there's an error:
library not found for -lnet.
And when I use homebrew install linnet, is says:
Warning: libnet-1.1.6 already installed.
It is the problem of library PATH.Flow the steps to solve this problem.
First, find where you install the library. For my case, the libnet is located in /usr/local/Cellar/libnet/1.1.6.
Second, run /usr/local/Cellar/libnet/1.1.6/bin/libnet-config.
Third, use -L to add the path when you link.
gcc *.o -L/usr/local/Cellar/libnet/1.1.6/lib -lnet.

How to disable Automake's test-driver script

Our project uses autoconf/automake for configuring and building. The building scripts work fine on Debian Squeeze and Wheezy (automake version 1.11.6), but don't work on Jessie, with a more recent version of automake (version 1.14.1). When I run make distcheck with the new automake version, it fails with
make[3]: Entering directory `/tmp/.../_build'
/bin/bash: ../autotools/test-driver: No such file or directory
Apparently, test-driver is a new script introduced by the recent automake version.
I tried to add autotools/test-driver into extra dependencies, but if it's present, distcheck fails with
.../_build/../autotools/test-driver: the following mandatory options are missing:
--test-name --log-file --trs-file
I'd appreciate any ideas how I could either update my build scripts to work with the new version or how to disable this new automake behavior.
Run automake -a at the top-level. Usually you should have a bootstrap script that invokes autotools with the correct flags for clean repository checkouts, or for when you make drastic changes to your build system.
And there's no need to set dependencies, unless you are custom-generating test-driver from a template or something.

CMake missing modules directory

I've installed CMake 2.8.11.2 package from CMake's website for Mac 64-bit. We recently upgraded a project from Qt 4 to Qt 5 and the CMake upgrade is mandatory for CMake to use Qt 5. However, when I type cmake . I get the following error:
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/Applications/CMake 2.8-11.app/Contents/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
I can confirm, there is no modules directory in the bin folder. I really don't know how to resolve this error, or how to get the modules needed.
Do hash -r to clear the cache, then do cmake --version.
It should work.
I had the same problem after upgrading on Ubuntu.
Removing cmake and the cmake-data package before performing the update solved it for me.
sudo apt-get remove cmake cmake-data
Now perform the update via
sudo -E add-apt-repository -y ppa:george-edison55/cmake-3.x
sudo -E apt-get update
sudo apt-get install cmake
This worked for me :
cd cmake-3.4.3
./bootstrap --prefix=/usr
make
sudo make install
Additionally, you may encounter the same error when running CMake from Cygwin. This may be caused by a PATH variable listing /bin before /usr/bin: in this case CMake is launched as /bin/cmake instead of /usr/bin/cmake, and trying to load modules from //share/cmake-X.Y.Z (which is a UNC path on Windows) instead of /usr/share/cmake-X.Y.Z.
Explicitly export'ing a correct CMAKE_ROOT isn't helpful, and cmake keeps displaying the same misleading message.
The issue can be solved by setting PATH to /usr/bin:/bin:/everything/else in your .bash_profile.
I was able to fix this error on Linux (for other who may be searching for answer on Linux) while trying to upgrade cmake 2.8.11 to 2.8.12 by exporting the CMAKE_ROOT environment variable like so:
export CMAKE_ROOT=/path_to_install/cmake-2.8.12.2-Linux-i386/share/cmake-2.8
The share directory should be on the same level as your bin directory.
I got the same error message upgrading cmake-3.5.1 to cmake-3.7.1 on Ubuntu 16.04.01 LTS. I just updated the repositories with
sudo apt-get update
Then
cmake --version
brought up the correct and upgraded cmake version and the error messages was gone.
In my opinion/case this is a developer "problem". I suspect this occurs mostly to new developers so I go a bit deeper to put it in the right perspective:
To "not mess with" the original system files used for daily work and separate the new compiled and volatile programs in a separate location it is common to not just change but add/mount a complete folder structure similar to the original OS folder structure in a special "development" location.
So more or less a mirrored folder structure of the original one but connected/linked to the original resources.
There for we need to add an environment variable to our user bash profile where we tell the system: "link our development folders to the following direction/dir."
On Arch Linux this is done in a file in ~/.bashrc - that is linked/forwarded in/by the ~/.bash_profile ("~" stands for /home/your user name/) and MacOS/Unix will be similar.
To do that there are 2 ways:
you can open the .bashrc file and add your environment path to the bottom of it
or
you can use "export" to put the environment variables to the right place in your user bash file.
for kde development e.g. you need to add a path at the end of the ~/.bashrc file like so:
# Adding the kdesrc-build directory to the path
export PATH="$HOME/kde/src/kdesrc-build:$PATH"
what basically tells the system: the development is done in the /home/user name/kde/src folder - there are your files. You can choose where you want to locate your development environment.
If you execute cmake it "thinks" your files are in the original OS folder and the "Could not find CMAKE_ROOT" - message will disappear because it finds all your files since properly linked from your development folder structure to your system folder structure.
So basically to solve the problem you could just execute cmake in the right system folder - it just could mess up your system if the program or make files are not proper done so it is pulled to the home folder development folder structure. And you just have to tell that cmake, so it can find all needed files to compile your stuff, including the CMAKE_ROOT.
Another problem could be that cmake isn't properly installed.
On Arch Linux systems that can be made sure by using the "sudo pacman -Syu cmake" command and it copies the files in the right direction and sets the right user variables to get it executed and reinstall cmake if necessary.
Btw, if you are on other systems like Debian make sure to use a Debian apt repository, it can differ from the Ubuntu repository, especially if you compile for the chosen system.
I tried to write a general "beginners in mind" overview to get em a fundamental picture. Executing cmake in the right folder solved that exact problem for me that was asked for.
(Actual that flags works for the actual cmake version from the official arch repository:
1:
cd /home/ivanovic/kde/src/program_name
than:
2:
cmake -S/home/ivanovic/kde/src/program_name -B/home/ivanovic/kde/build/program_name -DCMAKE_INSTALL_PREFIX=/home/ivanovic/kde/usr -DCMAKE_BUILD_TYPE=Debug
Pay attention that between -S and /home/... is no space, same at -B and /home/...
This worked fine for my kde system software builds.
)
If anyone gets the following error:
Modules directory not found in
/usr/share/cmake-3.20
cmake version 3.20.2
Solution which worked for me:
sudo cp -r /share/cmake-3.20 /usr/share/
The above command copies the cmake-3.20 directory from /share to /usr/share
This also happened to me on a fresh install of Ubuntu 21.04 and was fixed by installing it from "snap":
sudo snap install cmake --classic
(and then making sure that /snap/bin is in $PATH)
tl;dr: check the permission of folder /usr/local/share/cmake-x.xx.
I had a similar problem with the cmake that I build from source code. I compile the code with the following command.
./configure
make
sudo make install
and the binary files were placed into /usr/local/bin as expected. But I will encounter the same problem when executing cmake without sudo privilege. This is because the normal user don't have reading permission with folder /usr/local/share/cmake-3.xx.
The error went away when I give myself the permission to read/execute, with the command.
sudo chmod 755 /usr/local/share/cmake-3.xx
(xx will be the specific version that you installed.)