We just upgraded our build server from Ubuntu 16.x to 18.04.1, and I can no longer get Coverity to work.
Per Coverity Scan fails to build <stdlib.h> with _GNU_SOURCE defined, I have a Docker container on our Ubuntu 18.04.1 machine that installs the gcc-6 package (there's no other gcc installed in that container -- it's only gcc-6).
Per TravisCI / Coverity: Warning - No files were emitted, I also ran the following in my container: /coverity/cov-analysis-linux64-7.6.0/bin/cov-configure --comptype gcc --compiler gcc-6 --template. This seems to have generated the file /coverity/cov-analysis-linux64-7.6.0/config/coverity_config.xml
When I configure / build our software (libfabric, from https://github.com/ofiwg/libfabric) in the container, it builds just fine. However, if I try to build it via cov-build, I get compilation errors. For example, here's a cov-build command to build just a single file from libfabric:
# Clear out the Coverity meta data dir, just to be sure
$ rm -rf cov-data
$ /coverity/cov-analysis-linux64-7.6.0/bin/cov-build \
-dir cov-data make src/fi_tostr.lo
Here's a snipit of the relevant output from the cov-build/build-log.txt file showing where Coverity failed:
[STATUS] Compiling src/fi_tostr.c
/coverity/cov-analysis-linux64-7.6.0/bin/cov-emit --dir=/home/jsquyres/git/libfabric/cov-data --ignore_path=/tmp/cov-0/a35264b27887fab7178c6bf7ab1117a9/cov-configure --ignore_path=/tmp/cov-0/a35264b27887fab7178c6bf7ab1117a9/cov-0/49f277832f55e48469661625f8083203 -w --no_stdarg_builtin --incompat_proto --add_type_modifier=__coverity___fpreg --add_type_modifier=__coverity___float80 --add_type_modifier=__coverity___float128 --no_predefined_cplusplus --gnu_version=60400 --no_predefines --restrict --gnu_carriage_return_line_terminator --no_multiline_string --no_trigraphs --c99 --allow__bool --pre_preinclude /home/jsquyres/git/libfabric/cov-data/emit/394646c6191c/config/5fe0c6b2b8489d2ab05d2434d738b5ac/gcc-config-0/coverity-macro-compat.h --pre_preinclude /home/jsquyres/git/libfabric/cov-data/emit/394646c6191c/config/5fe0c6b2b8489d2ab05d2434d738b5ac/gcc-config-0/coverity-compiler-compat.h --preinclude /coverity/cov-analysis-linux64-7.6.0/config/template-gcc-config-8/../user_nodefs.h --gcc -I . -I include -I prov/sockets/include -I prov/sockets --sys_include /usr/lib/gcc/x86_64-linux-gnu/6/include --sys_include /usr/local/include --sys_include /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed --sys_include /usr/include/x86_64-linux-gnu --sys_include /usr/include -DHAVE_CONFIG_H -DNDEBUG -DPROVDLDIR="/usr/local/lib/libfabric" -DRDMADIR="#rdmadir#" -DSYSCONFDIR="/usr/local/etc" -D_GNU_SOURCE -D__OPTIMIZE__ -D__USE_XOPEN2K8 --type_sizes=e16Pdlx8fi4s2 --type_alignments=e16Pdlx8fi4s2 --size_t_type=m --wchar_t_type=i --ptrdiff_t_type=l src/fi_tostr.c
"/usr/lib/gcc/x86_64-linux-gnu/6/include/stdatomic.h", line 40: error #65:
expected a ";"
typedef _Atomic _Bool atomic_bool;
^
"/usr/lib/gcc/x86_64-linux-gnu/6/include/stdatomic.h", line 41: error #84:
invalid combination of type specifiers
typedef _Atomic char atomic_char;
^
Does anyone know how to make Coverity understand these types?
Related
It seems that any gcc created with crosstool-ng is missing omp.h, is there a way to solve this issue?
tomas#ubuntu:~/eHHAlgorithm/infoli_static$ /home/tomas/x-tools/arm-unknown-linux-uclibcgnueabi/bin/arm-unknown-linux-uclibcgnueabi-gcc infoli.c main.c -o infoli_arm_ns100_ss10_noout_nobench -lm -O3 -DNETWORK_SIZE=100 -DSIMULATION_STEPS=10 -DNO_OUTPUT -DNO_BENCH -static
infoli.c:3:10: fatal error: omp.h: No such file or directory
#include <omp.h>
^~~~~~~
compilation terminated.
If I use arm-linux-gnueabi-gcc, which I installed with apt-get directly in Ubuntu I don't get this error.
Solution:
./ct-ng arm-unknown-linux-uclibcgnueabi
./ct-ng menuconfig -> C compiler -> Compile libgomp (enable pressing < y >). Save changes.
./ct-ng build
This will enable the LIBGOMP option in the .config file:
tomas#ubuntu:~/crosstool-ng$ grep LIBGOMP .config*
.config:CT_CC_GCC_LIBGOMP=y
.config.old:# CT_CC_GCC_LIBGOMP is not set
i have MOTIF installed X11
a easy program is saved as hello.c
there is the following message
where can i get the X11/intrinsic.h , file ???
need help to compile
my system : MX-16 Linux Debian Jessie / i386
Code:
hans#mx1:~/Documents
$ cc push.c -o push -lXm -lXt -lX11
In file included from push.c:2:0:
/usr/include/Xm/Xm.h:59:27: fatal error: X11/Intrinsic.h: No such file or directory
#include <X11/Intrinsic.h>
^
compilation terminated.
hans#mx1:~/Documents
I installed the libxt-dev package on my Debian box:
apt-get install libxt-dev
Then the proper header will be installed:
# find /usr -name "Intrinsic.h" -print
/usr/include/X11/Intrinsic.h
Been using xv for several decades now -- I always find myself trying to rebuild it.
The copy on my system came from libxt-dev
$ locate Intrinsic
/usr/include/X11/Intrinsic.h
/usr/include/X11/IntrinsicI.h
/usr/include/X11/IntrinsicP.h
$ dpkg-query -S /usr/include/X11/Intrinsic.h
libxt-dev:amd64: /usr/include/X11/Intrinsic.h
You may want to install and use apt-file - you can ask it for a filename and it will tell you which packages (that you don't even have to have installed - just from the repos in your sources.lists) contain a file with that name
I have lua, that I isntalled using luarocks.
Edit: on a windows system
I successfully installed luasocket by downloading the luasocket-2.0.2-3.win32-x86.rock file from v202-3 from here. Its an older version, but it works.
However now I need to install yaml so I can work with yaml files. Now I am forced to install using a *.src.rock file or a .rockspec file.
I have tried:
luarocks install yaml which gives:
D:\user\workspace\_lua>luarocks install yaml
Warning: Failed searching manifest: Failed fetching manifest for https://luarocks.org - Failed downloading https://luarocks.org/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/https___luarocks.org/manifest
Warning: Failed searching manifest: Failed fetching manifest for https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/ - Failed downloading https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/https___raw.githubusercontent.com_rocks-moonscript-org_moonrocks-mirror_master_/manifest
Warning: Failed searching manifest: Failed fetching manifest for http://luafr.org/moonrocks/ - Failed downloading http://luafr.org/moonrocks/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/http___luafr.org_moonrocks_/manifest
Warning: Failed searching manifest: Failed fetching manifest for http://luarocks.logiceditor.com/rocks - Failed downloading http://luarocks.logiceditor.com/rocks/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/http___luarocks.logiceditor.com_rocks/manifest
Error: No results matching query were found.
So, then I downloaded yaml-1.1.2-1.src.rock and ran the command:
luarocks install yaml-1.1.2-1.src.rock
This told me that I had dependencies yaml --> lub --> luafilesystem. so then I downloaded:
luafilesystem-1.6.3-2.src.rock
lub-1.1.0-1.src.rock
yaml-1.1.2-1.src.rock
And I installed them one after the other with the result:
luarocks install luafilesystem-1.6.3-2.src.rock - OK
luarocks install lub-1.1.0-1.src.rock - OK
luarocks install yaml-1.1.2-1.src.rock - FAILED, see errors below
Error log:
D:\user\downloads\luarocks-2.3.0-win32\extras>luarocks install yaml-1.1.2-1.src.rock
Using yaml-1.1.2-1.src.rock... switching to 'build' mode
mingw32-gcc -O2 -c -o src/api.o -ID:/user/install/lua/luarocks/include src/api.c -Isrc
mingw32-gcc -O2 -c -o src/b64.o -ID:/user/install/lua/luarocks/include src/b64.c -Isrc
mingw32-gcc -O2 -c -o src/dumper.o -ID:/user/install/lua/luarocks/include src/dumper.c -Isrc
mingw32-gcc -O2 -c -o src/emitter.o -ID:/user/install/lua/luarocks/include src/emitter.c -Isrc
mingw32-gcc -O2 -c -o src/loader.o -ID:/user/install/lua/luarocks/include src/loader.c -Isrc
mingw32-gcc -O2 -c -o src/lyaml.o -ID:/user/install/lua/luarocks/include src/lyaml.c -Isrc
mingw32-gcc -O2 -c -o src/parser.o -ID:/user/install/lua/luarocks/include src/parser.c -Isrc
mingw32-gcc -O2 -c -o src/reader.o -ID:/user/install/lua/luarocks/include src/reader.c -Isrc
mingw32-gcc -O2 -c -o src/scanner.o -ID:/user/install/lua/luarocks/include src/scanner.c -Isrc
mingw32-gcc -O2 -c -o src/strtod.o -ID:/user/install/lua/luarocks/include src/strtod.c -Isrc
In file included from src/strtod.c:23:0:
src/strtod.c:24:17: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
extern int errno;
^
mingw32-gcc -O2 -c -o src/writer.o -ID:/user/install/lua/luarocks/include src/writer.c -Isrc
mingw32-gcc -shared -o yaml/core.dll src/api.o src/b64.o src/dumper.o src/emitter.o src/loader.o src/lyaml.o src/parser.o src/reader.o src/scanner.o src/strtod.o src/writer.o D:/user/install/lua/luarocks/lua5.1.lib -lMSVCR80
src/api.o:api.c:(.text+0x395): undefined reference to '_imp__yaml_realloc'
src/api.o:api.c:(.text+0x412): undefined reference to '_imp__yaml_string_extend'
:
LOTS OF THESE
:
src/scanner.o:scanner.c:(.text.unlikely+0x29d0): undefined reference to '_imp__yaml_queue_extend'
src/scanner.o:scanner.c:(.text.unlikely+0x29e8): undefined reference to '_imp__yaml_token_delete'
collect2.exe: error: ld returned 1 exit status
Error: Build error: Failed compiling module yaml/core.dll
Does anyone know why this build fails? - I got it directly from here: https://luarocks.org/modules/gaspard/yaml/1.1.2-1 which is the most downloaded version... so I guess it should work?
I mean, I can see what the error is... but I don't understand why there should be an error. How can I resolve this?... Any help appreciated :)
UPDATE
Thanks to siffiejoe's comment, I was able to compile the yaml rock. Here is the output:
D:\user\downloads\luarocks-2.3.0-win32\extras>luarocks install yaml-1.1.2-1.src.rock CC="gcc -DYAML_DECLARE_STATIC"
Using yaml-1.1.2-1.src.rock... switching to 'build' mode
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/api.o -ID:/user/install/lua/luarocks/include src/api.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/b64.o -ID:/user/install/lua/luarocks/include src/b64.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/dumper.o -ID:/user/install/lua/luarocks/include src/dumper.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/emitter.o -ID:/user/install/lua/luarocks/include src/emitter.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/loader.o -ID:/user/install/lua/luarocks/include src/loader.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/lyaml.o -ID:/user/install/lua/luarocks/include src/lyaml.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/parser.o -ID:/user/install/lua/luarocks/include src/parser.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/reader.o -ID:/user/install/lua/luarocks/include src/reader.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/scanner.o -ID:/user/install/lua/luarocks/include src/scanner.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/strtod.o -ID:/user/install/lua/luarocks/include src/strtod.c -Isrc
In file included from src/strtod.c:23:0:
src/strtod.c:24:17: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
extern int errno;
^
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/writer.o -ID:/user/install/lua/luarocks/include src/writer.c -Isrc
mingw32-gcc -shared -o yaml/core.dll src/api.o src/b64.o src/dumper.o src/emitter.o src/loader.o src/lyaml.o src/parser.o src/reader.o src/scanner.o src/strtod.o src/writer.o D:/user/install/lua/luarocks/lua5.1.lib -lMSVCR80
Updating manifest for D:\user\install\lua\luarocks\systree/lib/luarocks/rocks
yaml 1.1.2-1 is now built and installed in D:\user\install\lua\luarocks\systree (license: MIT)
So it says it is installed. However when I try to use the yaml packge it does not find it:
local yaml = require("yaml")
local data = yaml.load("mytest.yaml")
The system reports that it can't find yaml.lua or yaml.dll. I then searched *.lua and *.dll in my luarocks folder I found:
D:\user\install\lua\luarocks\systree>dir *.lua *.dll /b /s
D:\user\install\lua\luarocks\systree\lib\lua\5.1\lfs.dll
D:\user\install\lua\luarocks\systree\lib\lua\5.1\mime\core.dll
D:\user\install\lua\luarocks\systree\lib\lua\5.1\socket\core.dll
D:\user\install\lua\luarocks\systree\lib\lua\5.1\yaml\core.dll
D:\user\install\lua\luarocks\systree\lib\luarocks\rocks\luafilesystem\1.6.3-2\tests\test.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\ltn12.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\mime.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Autoload.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Dir.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\init.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Param.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Template.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\ftp.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\http.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\smtp.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\tp.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\url.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\yaml\init.lua
For example, I managed to install luasocket with luarocks install luasocket-2.0.2-3.win32-x86.rock because there was a .rock file available. And so you can see there is a socket.lua. For yaml, lub and luafilesystem I can see various install locations, but there is no .lua or .dll files...
I searched more for yaml specifically:
D:\user\install\lua\luarocks\systree>dir *yaml* /b /s
D:\user\install\lua\luarocks\systree\lib\lua\5.1\yaml
D:\user\install\lua\luarocks\systree\lib\luarocks\rocks\yaml
D:\user\install\lua\luarocks\systree\lib\luarocks\rocks\yaml\1.1.2-1\yaml-1.1.2-1.rockspec
D:\user\install\lua\luarocks\systree\share\lua\5.1\yaml
ehh... so then I went and cloned the project from git (had to download the zip file because my stupid IT blocked my git clone ... (port 443).
So finally got that sorted, then in the yaml-master folder I tried:
luarocks make yaml-1.1.2-1.rockspec CC-"gcc -DYAML_DECLARE_STATIC"
This had the same effect as before. So now I have tried both .src.rock and .rockspec types...
I am stuck again :(
UPDATE 2
When I built from git, there was a file called yaml.lua in the top level. But all it contains is the text yaml/init.lua ... not sure what to do with that - tried copying it into the my ..install\lua\luarocks\systree\share\lua\5.1 dir, but when I run my test lua projam it gives an error.... what is going on, it can't be this hard to install :(
UPDATE 3
Following on from siffiejoe's great answer, I have more or less got this yaml installed. But I have a bug running it:
Here is my lua script:
package.path = "D:\\user\\install\\lua\\luarocks\\systree\\share\\lua\\5.1\\?\\init.lua;" .. package.path
print("package.path: " .. package.path)
local yaml = require("yaml")
local data = yaml.load("mytest.yaml")
I am manually adding the lua path for now while I am testing. When I run this I get the window:
And my log looks like:
D:\user\install\lua\luarocks\systree\share\lua\5.1\?\init.lua;D:\user\install\lua\luarocks\systree\share\lua\5.1\?.lua;D:\user\install\lua\luarocks\systree\share\lua\5.1\?\init.lua;./?.lua;./?/init.lua;./lua/?.lua;./lua/?/init.lua;D:\user\install\lua\zerobrane\lualibs/?/?.lua;D:\user\install\lua\zerobrane\lualibs/?.lua;D:\user\install\lua\zerobrane\lualibs/?/?/init.lua;D:\user\install\lua\zerobrane\lualibs/?/init.lua
D:\user\install\lua\zerobrane\bin\lua.exe: error loading module 'lfs' from file 'D:\user\install\lua\luarocks\systree\lib\lua\5.1\lfs.dll':
The specified procedure could not be found.
stack traceback:
[C]: at 0x66df0460
[C]: in function 'require'
...\install\lua\luarocks\systree\share\lua\5.1\lub\init.lua:17: in main chunk
[C]: in function 'require'
...install\lua\luarocks\systree\share\lua\5.1\yaml\init.lua:25: in main chunk
[C]: in function 'require'
D:\user\workspace\_lua\myluatest.lua:3: in main chunk
[C]: at 0x00402a57
Program completed in 56.64 seconds (pid: 15856).
So it appears to come back to this MSVCR80.dll ... this is not making sense to me, I assume this is do with microsoft... Some things I have read about it could be a corrupt MSVCR80.dll that needs replacing or somthing. But I am not yet sure about why this is occuring. Any thoughts?
The include file src/yaml.h from the github repository contains the following preprocessor code:
#ifdef WIN32
# if defined(YAML_DECLARE_STATIC)
# define YAML_DECLARE(type) type
# elif defined(YAML_DECLARE_EXPORT)
# define YAML_DECLARE(type) __declspec(dllexport) type
# else
# define YAML_DECLARE(type) __declspec(dllimport) type
# endif
#else
# define YAML_DECLARE(type) type
#endif
That means that on Windows all yaml-related functions by default are decorated with __declspec(dllimport) (the _imp__ prefixes in the linker error messages were hints). Because of this the linker expects those functions to be in an external DLL. But the yaml code is bundled and compiled together with the Lua binding into a single DLL yaml\core.dll, and so the linker complains. The correct way to fix this is to remove all import/export-related decorations from the yaml functions, and this can be achieved by defining YAML_DECLARE_STATIC. This macro should definitely be set in the rockspec (I'll post a bug report later), but a quick and dirty solution is to set it via the CC variable on the commandline:
luarocks install yaml-1.1.2-1.src.rock CC="mingw32-gcc -DYAML_DECLARE_STATIC"
After that there should be a yaml\core.dll file and a yaml\init.lua file somewhere in your LuaRocks directory. To use the Lua yaml binding you have to make sure that a require("yaml") loads the yaml\init.lua file, and that require("yaml.core") loads yaml\core.dll. This can be achieved by adding to package.path/package.cpath (from within your Lua script) or preferably by adding to LUA_PATH/LUA_CPATH. Since the installed LuaSocket already works, you probably have LUA_PATH/LUA_CPATH mostly set up correctly, but the yaml binding uses a different approach for loading its main Lua module than LuaSocket: LuaSocket has socket.lua for require("socket"), but yaml has yaml\init.lua for require("yaml"). This approach has the advantage that any Lua submodules (e.g. yaml.a) would be in the same directory as the code for the main Lua module. Anyway, you also have to add
D:\user\install\lua\luarocks\systree\share\lua\5.1\?\init.lua
to your LUA_PATH environment variable.
Btw., the yaml.lua file you found in the github repository is a symbolic link and won't work correctly on Windows anyway (but it could interfere, so you shouldn't put it into your rocks tree). It's only there for convenience during development.
I was trying to build eglibc-2.19 on Ubuntu 14.04 LTS which I downloaded through
apt-get source libc6
I followed the INSTALL instructions but got this error when it ran into nptl
gcc sem_init.c -c -std=gnu99 -fgnu89-inline -fno-stack-protector -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes -U_FORTIFY_SOURCE -I../include -I/home/gpanda/wksp/glibc/tmp2/glibc-build/nptl -I/home/gpanda/wksp/glibc/tmp2/glibc-build -I../sysdeps/unix/sysv/linux/x86_64/64/nptl -I../sysdeps/unix/sysv/linux/x86_64/64 -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../nptl/sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../libpthread/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../libpthread/sysdeps/posix -I../nptl/sysdeps/x86_64/64 -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I../libpthread/include -I../libpthread -I../nptl -I../ports -I.. -I../libio -I. -I../libpthread/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -DIS_IN_libpthread=1 -DIN_LIB=libpthread -o /home/gpanda/wksp/glibc/tmp2/glibc-build/nptl/sem_init.o -MD -MP -MF /home/gpanda/wksp/glibc/tmp2/glibc-build/nptl/sem_init.o.dt -MT /home/gpanda/wksp/glibc/tmp2/glibc-build/nptl/sem_init.o
In file included from sem_init.c:20:0:
../libpthread/include/semaphore.h:28:0: warning: "SEM_FAILED" redefined [enabled by default]
#define SEM_FAILED ((void *) 0)
^
In file included from ../libpthread/include/semaphore.h:26:0,
from sem_init.c:20:
../nptl/sysdeps/unix/sysv/linux/x86/bits/semaphore.h:33:0: note: this is the location of the previous definition
#define SEM_FAILED ((sem_t *) 0)
^
In file included from sem_init.c:20:0:
../libpthread/include/semaphore.h:30:28: error: conflicting types for ‘sem_t’
typedef struct __semaphore sem_t;
^
In file included from ../libpthread/include/semaphore.h:26:0,
from sem_init.c:20:
../nptl/sysdeps/unix/sysv/linux/x86/bits/semaphore.h:40:3: note: previous declaration of ‘sem_t’ was here
} sem_t;
^
make[2]: *** [/home/gpanda/wksp/glibc/tmp2/glibc-build/nptl/sem_init.o] Error 1
make[2]: Leaving directory `/home/gpanda/wksp/glibc/tmp2/eglibc-2.19/nptl'
make[1]: *** [nptl/subdir_lib] Error 2
make[1]: Leaving directory `/home/gpanda/wksp/glibc/tmp2/eglibc-2.19'
make: *** [all] Error 2
Is this some kind of conflict between libpthread and nptl? How to fix this problem?
Thanks in advance.
Consider LinuxThreads has been superseded by NPTL, so I just removed the add-on libpthread from the eglibc directory, and re-did the configure and make, then everything seems to be ok now.
see LinuxThreads,NPTL
BTW, since I didn't use the standard /usr path as the "--prefix=" option for configure, so I need copy libstdc++.so.6 and libgcc_s.so.1 to my current build path to get "make check" pass.
see glibc Known_testsuite_failures
I got the same error because I ran a plain ./configure --prefix=/opt, so I ran apt-get source -b eglibc instead and I noted the configure flags it used:
(exec 3>&1; exit `( ( ( cd build-tree/i386-libc && CC="i686-linux-gnu-gcc-4.8" CXX="i686-linux-gnu-g++-4.8" AUTOCONF=false MAKEINFO=: /home/sashoalm/Workspace/apt-get-source/libc/eglibc-2.19/configure --host=i686-linux-gnu --build=$configure_build --prefix=/usr --without-cvs --enable-add-ons=libidn,"nptl " --enable-profile --without-selinux --enable-stackguard-randomization --enable-obsolete-rpc --with-pkgversion="Ubuntu EGLIBC 2.19-0ubuntu6.9" --with-bugurl="https://bugs.launchpad.net/ubuntu/+source/eglibc/+bugs" --with-headers=/home/sashoalm/Workspace/apt-get-source/libc/eglibc-2.19/debian/include --enable-kernel=2.6.24 --with-selinux --enable-multi-arch ) 2>&1 3>&-; echo $? >&4) | tee -a build-tree/log-build-i686-linux-gnu-libc >&3) 4>&1`)
The command is rather involved, more complex than usual for apt-get source, since glibc insists on being built from a separate directory. The actual configure flags are:
--host=i686-linux-gnu --build=$configure_build --prefix=/usr --without-cvs --enable-add-ons=libidn,"nptl " --enable-profile --without-selinux --enable-stackguard-randomization --enable-obsolete-rpc --with-pkgversion="Ubuntu EGLIBC 2.19-0ubuntu6.9" --with-bugurl="https://bugs.launchpad.net/ubuntu/+source/eglibc/+bugs" --with-headers=/home/sashoalm/Workspace/apt-get-source/libc/eglibc-2.19/debian/include --enable-kernel=2.6.24 --with-selinux --enable-multi-arch
It works with those arguments of course, since that's what Ubuntu maintainers used to compile the package with.
I don't really know which of those flags prevents the error, but if you use that command, or the exact arguments provided by apt-get source -b eglibc on your Ubuntu system, it should work well enough.
I have built glibc 2.14 and installed it in directory ~/GLIBC/glibc_install. Now I want to build and run programs using this C library instead of my system's default C library.
To be sure that I was using my custom glibc, I added a call to puts into glibc/stdio-common/printf.c:__printf to print a message.
Then I rebuilt and reinstalled glibc.
Then I wrote a "Hello, World" program and tried to compile and link it as follows:
gcc -nodefaultlibs -static -lgcc -L~/GLIBC/glibc_install/lib -o myprog myprog.c
But I get the following linker error report:
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start':
(.text+0x19): undefined reference to `__libc_csu_init'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start':
(.text+0x25): undefined reference to `__libc_start_main'
/tmp/ccACTQEp.o: In function `main':
c1.c:(.text+0xa): undefined reference to `puts'
collect2: ld returned 1 exit status
What am I doing wrong?
Following a couple of suggestions from the glibc help mailing list (libc-help#sourceware.org), I have a solution. It turns out that this task is a bit tricky because you have to tell the linker to omit everything it would normally include automatically (and silently), and then include back everything that it needs, including a bunch of start and end files. Some of the start and end files come from libc and some come from gcc, so the make rule is a bit complicated. Below is a general sample makefile to illustrate the approach. I will assume that you are building a program called prog from a source file called prog.c and that you have installed your custom glibc in directory /home/my_acct/glibc_install.
TARGET = prog
OBJ = $(TARGET).o
SRC = $(TARGET).c
CC = gcc
CFLAGS = -g
LDFLAGS = -nostdlib -nostartfiles -static
GLIBCDIR = /home/my_acct/glibc_install/lib
STARTFILES = $(GLIBCDIR)/crt1.o $(GLIBCDIR)/crti.o `gcc --print-file-name=crtbegin.o`
ENDFILES = `gcc --print-file-name=crtend.o` $(GLIBCDIR)/crtn.o
LIBGROUP = -Wl,--start-group $(GLIBCDIR)/libc.a -lgcc -lgcc_eh -Wl,--end-group
$(TARGET): $(OBJ)
$(CC) $(LDFLAGS) -o $# $(STARTFILES) $^ $(LIBGROUP) $(ENDFILES)
$(OBJ): $(SRC)
$(CC) $(CFLAGS) -c $^
clean:
rm -f *.o *.~ $(TARGET)
Setup 1: compile your own glibc without dedicated GCC and use it
Without static also working at: Multiple glibc libraries on a single host
This setup might work and is quick as it does not recompile the whole GCC toolchain, just glibc.
But it is not reliable as it uses host C runtime objects such as crt1.o, crti.o, and crtn.o provided by glibc. This is mentioned at: https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location Those objects do early setup that glibc relies on, so I wouldn't be surprised if things crashed in wonderful and awesomely subtle ways.
For a more reliable setup, see Setup 2 below.
Build glibc and install locally:
export glibc_install="$(pwd)/glibc/build/install"
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
mkdir build
cd build
../configure --prefix "$glibc_install"
make -j `nproc`
make install -j `nproc`
Setup 1: verify the build
test_glibc.c
#define _GNU_SOURCE
#include <assert.h>
#include <gnu/libc-version.h>
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>
atomic_int acnt;
int cnt;
int f(void* thr_data) {
for(int n = 0; n < 1000; ++n) {
++cnt;
++acnt;
}
return 0;
}
int main(int argc, char **argv) {
/* Basic library version check. */
printf("gnu_get_libc_version() = %s\n", gnu_get_libc_version());
/* Exercise thrd_create from -pthread,
* which is not present in glibc 2.27 in Ubuntu 18.04.
* https://stackoverflow.com/questions/56810/how-do-i-start-threads-in-plain-c/52453291#52453291 */
thrd_t thr[10];
for(int n = 0; n < 10; ++n)
thrd_create(&thr[n], f, NULL);
for(int n = 0; n < 10; ++n)
thrd_join(thr[n], NULL);
printf("The atomic counter is %u\n", acnt);
printf("The non-atomic counter is %u\n", cnt);
}
Compile and run with test_glibc.sh:
#!/usr/bin/env bash
set -eux
rm -rf tmp
mkdir tmp
gcc \
-L "${glibc_install}/lib" \
-I "${glibc_install}/include" \
-Wl,--rpath="${glibc_install}/lib" \
-Wl,--dynamic-linker="${glibc_install}/lib/ld-linux-x86-64.so.2" \
-static \
-std=c11 \
-o tmp/test_glibc.out \
-v \
test_glibc.c \
-pthread \
;
sudo chroot tmp /test_glibc.out
The program outputs the expected:
gnu_get_libc_version() = 2.28
The atomic counter is 10000
The non-atomic counter is 8674
even though we ran it on a clean chroot, so the -static must have worked.
Command adapted from https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location but --sysroot made it fail with:
cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install
so I removed it.
ldd output confirms that the ldd and libraries that we've just built are actually being used as expected:
+ ldd test_glibc.out
linux-vdso.so.1 (0x00007ffe4bfd3000)
libpthread.so.0 => /home/ciro/glibc/build/install/lib/libpthread.so.0 (0x00007fc12ed92000)
libc.so.6 => /home/ciro/glibc/build/install/lib/libc.so.6 (0x00007fc12e9dc000)
/home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)
The gcc compilation debug output shows that my host runtime objects were used, which is bad as mentioned previously, but I don't know how to work around it, e.g. it contains:
COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o
Setup 1: modify glibc
Now let's modify glibc with:
diff --git a/nptl/thrd_create.c b/nptl/thrd_create.c
index 113ba0d93e..b00f088abb 100644
--- a/nptl/thrd_create.c
+++ b/nptl/thrd_create.c
## -16,11 +16,14 ##
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
+#include <stdio.h>
+
#include "thrd_priv.h"
int
thrd_create (thrd_t *thr, thrd_start_t func, void *arg)
{
+ puts("hacked");
_Static_assert (sizeof (thr) == sizeof (pthread_t),
"sizeof (thr) != sizeof (pthread_t)");
Then recompile and re-install glibc, and recompile and re-run our program:
cd glibc/build
make -j `nproc`
make -j `nproc` install
./test_glibc.sh
and we see hacked printed a few times as expected.
This further confirms that we actually used the glibc that we compiled and not the host one.
Tested on Ubuntu 18.04.
Setup 2: crosstool-NG pristine setup
This is an alternative to setup 1, and it is the most correct setup I've achieved far: everything is correct as far as I can observe, including the C runtime objects such as crt1.o, crti.o, and crtn.o.
In this setup, we will compile a full dedicated GCC toolchain that uses the glibc that we want.
The only downside to this method is that the build will take longer. But I wouldn't risk a production setup with anything less.
crosstool-NG is a set of scripts that downloads and compiles everything from source for us, including GCC, glibc and binutils.
Yes the GCC build system is so bad that we need a separate project for that.
This setup is only not perfect because crosstool-NG does not support building the executables without extra -Wl flags, which feels weird since we've built GCC itself. But everything seems to work, so this is only an inconvenience.
Get crosstool-NG and configure it:
git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
git checkout a6580b8e8b55345a5a342b5bd96e42c83e640ac5
export CT_PREFIX="$(pwd)/.build/install"
export PATH="/usr/lib/ccache:${PATH}"
./bootstrap
./configure --enable-local
make -j `nproc`
./ct-ng x86_64-unknown-linux-gnu
./ct-ng menuconfig
The only mandatory option that I can see, is making it match your host kernel version to use the correct kernel headers. Find your host kernel version with:
uname -a
which shows me:
4.15.0-34-generic
so in menuconfig I do:
Operating System
Version of linux
so I select:
4.14.71
which is the first equal or older version. It has to be older since the kernel is backwards compatible.
Now you can build with:
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
and now wait for about thirty minutes to two hours for compilation.
Setup 2: optional configurations
The .config that we generated with ./ct-ng x86_64-unknown-linux-gnu has:
CT_GLIBC_V_2_27=y
To change that, in menuconfig do:
C-library
Version of glibc
save the .config, and continue with the build.
Or, if you want to use your own glibc source, e.g. to use glibc from the latest git, proceed like this:
Paths and misc options
Try features marked as EXPERIMENTAL: set to true
C-library
Source of glibc
Custom location: say yes
Custom location
Custom source location: point to a directory containing your glibc source
where glibc was cloned as:
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
Setup 2: test it out
Once you have built he toolchain that you want, test it out with:
#!/usr/bin/env bash
set -eux
install_dir="${CT_PREFIX}/x86_64-unknown-linux-gnu"
rm -rf tmp
mkdir tmp
PATH="${PATH}:${install_dir}/bin" \
x86_64-unknown-linux-gnu-gcc \
-Wl,--dynamic-linker="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2" \
-Wl,--rpath="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib" \
-static \
-v \
-o tmp/test_glibc.out \
test_glibc.c \
-pthread \
;
sudo chroot tmp /test_glibc.out
Everything seems to work as in Setup 1, except that now the correct runtime objects were used:
COLLECT_GCC_OPTIONS=/home/ciro/crosstool-ng/.build/install/x86_64-unknown-linux-gnu/bin/../x86_64-unknown-linux-gnu/sysroot/usr/lib/../lib64/crt1.o
Setup 2: failed efficient glibc recompilation attempt
It does not seem possible with crosstool-NG, as explained below.
If you just re-build;
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
then your changes to the custom glibc source location are taken into account, but it builds everything from scratch, making it unusable for iterative development.
If we do:
./ct-ng list-steps
it gives a nice overview of the build steps:
Available build steps, in order:
- companion_tools_for_build
- companion_libs_for_build
- binutils_for_build
- companion_tools_for_host
- companion_libs_for_host
- binutils_for_host
- cc_core_pass_1
- kernel_headers
- libc_start_files
- cc_core_pass_2
- libc
- cc_for_build
- cc_for_host
- libc_post_cc
- companion_libs_for_target
- binutils_for_target
- debug
- test_suite
- finish
Use "<step>" as action to execute only that step.
Use "+<step>" as action to execute up to that step.
Use "<step>+" as action to execute from that step onward.
therefore, we see that there are glibc steps intertwined with several GCC steps, most notably libc_start_files comes before cc_core_pass_2, which is likely the most expensive step together with cc_core_pass_1.
In order to build just one step, you must first set the "Save intermediate steps" in .config option for the intial build:
Paths and misc options
Debug crosstool-NG
Save intermediate steps
and then you can try:
env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`
but unfortunately, the + required as mentioned at: https://github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536
Note however that restarting at an intermediate step resets the installation directory to the state it had during that step. I.e., you will have a rebuilt libc - but no final compiler built with this libc (and hence, no compiler libraries like libstdc++ either).
and basically still makes the rebuild too slow to be feasible for development, and I don't see how to overcome this without patching crosstool-NG.
Furthermore, starting from the libc step didn't seem to copy over the source again from Custom source location, further making this method unusable.
Bonus: stdlibc++
A bonus if you're also interested in the C++ standard library: How to edit and re-build the GCC libstdc++ C++ standard library source?
You command line is just bogus. Try:
gcc -nodefaultlibs -static -L~/GLIBC/glibc_install/lib -o myprog myprog.c -lgcc -lc -lgcc -lc
or similar. You omitted -lc, and also erroneously had your libraries before your input files.
And you were searching for a library called libibgcc rather than libgcc...