I am trying to compile the application Darling and I can not get the required OpenSuse packages right. The instructions they provide are for Debian, Ubuntu, Arch and Fedora. I get the error:
bigb@linux-17qf:~/darling/build> make
0%] Linking C executable elfloader_dummy32
/usr/bin/ld: cannot find **crtbeginS.o**: No such file or directory
clang-7.0.1: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/build.make:121: src/libelfloader/native/elfloader_dummy32] Error 1
make[1]: *** [CMakeFiles/Makefile2:806: src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
I was able to find the missing file. It is part of the gcc7 package.
/usr/lib64/gcc/x86_64-suse-linux/7/crtbeginS.o
Because a quick search returns a multitude of hits,
I suspect the file isn’t actually provided, it is dynamically built.
If a pre-built library was provided, I’m sure it wouldn’t be missing so often.
Inspect your log prior to your snippet, I suspect you’ll find other fails which can provide you a clue why you’re failing.
And,
Because Fedora uses the same naming convention as openSUSE, you should be able to use that list of dependencies, just install using our zypper command instead of dnf, and maybe install the C Development pattern.
I have installed this pattern as well. Issue is the same. I have started over and there is a warning as well:
bigb@linux-17qf:~/darling/build> make
Scanning dependencies of target elfloader_dummy32
0%] Building C object src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/elfcalls.o
0%] Building C object src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/threads.o
**/home/bigb/darling/src/libelfloader/native/threads.c:193:2: warning: implicit
declaration of function 'pthread_getattr_np' is invalid in C99
-Wimplicit-function-declaration]**
pthread_getattr_np(pthread_self(), &attr);
^
1 warning generated.
0%] Linking C executable elfloader_dummy32
/usr/bin/ld: cannot find crtbeginS.o: Nincs ilyen fájl vagy könyvtár
clang-7.0.1: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/build.make:121: src/libelfloader/native/elfloader_dummy32] Error 1
make[1]: *** [CMakeFiles/Makefile2:806: src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
I strongly suspect you have installed the wrong package dependencies. Inspecting the Darling build instructions and the Fedora Dependency package list, I see that you must compile on a 64-bit system and by their name I suspect that your build should target the x686 architecture which IIRC is not 32-bit. Oddly, the Ubuntu/Debian package list includes some 32-bit packages, but those should not be relevant to RPM systems like openSUSE. Although there may be something hidden, I don’t see anything in the Package Dependencies that suggests to me an attempt to build targeting the i386 architecture like what you see in your posted log.
So the first thing I’d ask you to do is run the following command and post the results
Other build requirements seem to be satisfied, in particular a kernel 4.9 or later… run the following command to be certain you have fully updated your system, as of today your kernel should be 4.12.x
zypper up
I assume you are following the Build instructions faithfully…
Each day you attempt a new build, be sure to update your github source with a “pull” to be certain you have even the latest contributions
git pull
Then, execute the build commands as described starting with locating your cursor to the source root
Hi
Yes, there is no i386 target in openSUSE releases anymore just i586/i686 there should be somewhere to re-configure (set in cmake speak) this.
@Tsu2, the OP does have appear to have all the packages required installed, it’s a code issue for sure as I’m hitting the exact same issue building as an rpm based on the Fedora spec file included in the Github repo.
There are plenty of testing/checks in the cmake part (aka ./configure) to identify missing stuff and errors out before even getting the chance to run make.
If you compile 32 bit binary, you need at the very least gcc7-32bit package that provides corresponding run-time support. You will also need 32 bit versions of every other library used by your binary.
I do not think there is single pattern that installs them. Nor are development packages available for every 32 bit run-time, I think they are created on case by case basis.
I’m not even sure why anyone would want to compile an i386 binary.
I downloaded source and now see all those i386 files, and tests (without actually compiling), but I see also that x86-64 is a supported target architecture… probably should be configured for that somewhere.
And, there sure are a lot of cmake config files… I guess someone really serious about this would have to go through them and find the line of code that sets the target to x86-64. Maybe an impatient “dirty” approach could be to simply change every configuration reference from i386 to x86-64 and see if it works…
No, at least I wouldn’t recommend removing 32-bit packages… I’d frown on the use of 32-bit packages in a 64-bit target, but it’ll work… That’s the beauty of x64 that it supports backwards compatibility with 32-bit code.
Your posted list looks fine, but we’re trusting that your log doesn’t have anything else that’s critically important.
Then,
We don’t know how well the code is written, whether it can find the files provided for x86-64.
And, we don’t know why the build decided to build i386 (it’s a very early architecture which might work for its early base compatibility, but is not often preferred). Is it because the build failed at trying to build x86-64 or because it was manually chosen somewhere?
My speculative idea to try to force x86-64 was to try to over-ride any other logic or choice to build i386, but it’s just that… a speculative try.
You might ask the Darling developers about what you’re seeing, they might have ready answers for several of the things we’re guessing at.
linux-17qf:/home/bigb/darling/build # cmake ..
-- The C compiler identification is Clang 7.0.1
-- The CXX compiler identification is Clang 7.0.1
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang++
-- Check for working CXX compiler: /usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is Clang
-- Found assembler: /usr/bin/clang
-- The ASM-ATT compiler identification is GNU
-- Found assembler: /usr/bin/as
-- Found dsymutil: /usr/bin/dsymutil
-- Compiler include path detected as /usr/lib64/clang/7.0.1/include/
-- Found BISON: /usr/bin/bison (found version "3.0.4")
-- Found FLEX: /usr/bin/flex (found version "2.6.4")
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2")
-- Checking for module 'fuse'
-- Found fuse, version 2.9.7
-- Performing Test CFLAG_Wall
-- Performing Test CFLAG_Wall - Success
-- Performing Test CFLAG_Wno_unknown_pragmas
-- Performing Test CFLAG_Wno_unknown_pragmas - Success
-- Performing Test CFLAG_Wno_unused_variable
-- Performing Test CFLAG_Wno_unused_variable - Success
-- Checking for module 'egl'
-- Found egl, version 18.3.2
-- Checking for module 'cairo'
-- Found cairo, version 1.15.10
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.9.0")
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.34")
-- Found TIFF: /usr/lib64/libtiff.so (found version "4.0.9")
-- Found JPEG: /usr/lib64/libjpeg.so
-- Checking for module 'fontconfig'
-- Found fontconfig, version 2.12.6
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - not found
-- Looking for dnet_ntoa in dnet
-- Looking for dnet_ntoa in dnet - not found
-- Looking for dnet_ntoa in dnet_stub
-- Looking for dnet_ntoa in dnet_stub - not found
-- Looking for gethostbyname
-- Looking for gethostbyname - not found
-- Looking for gethostbyname in nsl
-- Looking for gethostbyname in nsl - not found
-- Looking for gethostbyname in bsd
-- Looking for gethostbyname in bsd - not found
-- Looking for connect
-- Looking for connect - not found
-- Looking for connect in socket
-- Looking for connect in socket - not found
-- Looking for remove
-- Looking for remove - not found
-- Looking for remove in posix
-- Looking for remove in posix - not found
-- Looking for shmat
-- Looking for shmat - not found
-- Looking for shmat in ipc
-- Looking for shmat in ipc - not found
-- Found X11: /usr/lib64/libX11.so
-- Found OpenGL: /usr/lib64/libOpenGL.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bigb/darling/build
And then make stops as below:
linux-17qf:/home/bigb/darling/build # make
Scanning dependencies of target elfloader_dummy32
0%] Building C object src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/elfcalls.o
0%] Building C object src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/threads.o
/home/bigb/darling/src/libelfloader/native/threads.c:193:2: warning: implicit declaration
of function 'pthread_getattr_np' is invalid in C99 -Wimplicit-function-declaration]
pthread_getattr_np(pthread_self(), &attr);
^
1 warning generated.
0%] Linking C executable elfloader_dummy32
/usr/bin/ld: cannot find crtbeginS.o: No such file or directory
clang-7.0.1: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/build.make:121: src/libelfloader/native/elfloader_dummy32] Error 1
make[1]: *** [CMakeFiles/Makefile2:806: src/libelfloader/native/CMakeFiles/elfloader_dummy32.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
Hi
Your cmake output is fine (mine is the same), the issue as explained is there is no i386 build target, the only 32bit build targets in openSUSE are i586/i686…
But the big question is why the i386 build target?
Both the posted log and packages indicate support for the x86-64 build target, so why isn’t that the build target?
Unless someone wants to dig through the code,
Darling support should be asked how to re-target.
But the big question is why the i386 build target? That’s the beauty of x64 that it supports backwards compatibility with 32-bit code.
With x64 the CPU architecture, yes, it’s basically a superset of IA-32, so you can run 32-bit and 16-bit i386 code on it. With libraries built for x64, no, you cannot run 32-bit or 16-bit with them, it’s ABI-incompatible (e.g. pointers have different sizes).
That’s why, even on Linux, if you want to run 32-bit software, you have to install a separate set of libraries. For example, on my system here, I have both /usr/lib/libc-2.29.so and /usr/lib64/libc-2.29.so. We need to build the same for Darling, except it ends up in a one .dylib file consisting of multiple (in this case two) of sub-Mach-Os for different architectures.
Hi
In openSUSE the 32bit libs are built (Tumbleweed does build a i586 release, openQA tested, but still can have issues), but there is no i386 anymore…