Installing rb-gsl gem using Cygwin - c

I'm having issues installing rb-gsl under Windows using Cygwin. I'm using the RubyInstaller for Windows with the dev kit installed. I've installed Cygwin and the GSL runtime, gsl-apps, gsl-devel and gsl-doc packages. When issuing a gem install command I get the following:
$ gem.bat install "C:\Documents and Settings\jzh3fd.2UA1071FGF\Desktop\gsl-1.14
.7.gem"
Temporarily enhancing PATH to include DevKit...
Building native extensions. This could take a while...
ERROR: Error installing C:\Documents and Settings\jzh3fd.2UA1071FGF\Desktop\gsl
-1.14.7.gem:
ERROR: Failed to build gem native extension.
C:/Ruby192/bin/ruby.exe extconf.rb
checking gsl version... 1.14
checking gsl cflags... -I/usr/include
checking for main() in -lcblas... no
checking gsl libs... -L/usr/lib -lgsl -lgslcblas -lm
checking for round()... no
checking for rngextra/rngextra.h... no
checking for qrngextra/qrngextra.h... no
checking for ool/ool_version.h... no
checking for tensor/tensor.h... no
checking for jacobi.h... no
checking for gsl/gsl_cqp.h... no
checking for gsl/gsl_multimin_fsdf.h... no
checking for gsl_poly_solve_quartic() in -lgsl... no
checking for gsl_eigen_francis() in -lgsl... no
checking for ndlinear/gsl_multifit_ndlinear.h... no
checking for alf/alf.h... no
checking rb-gsl version...1.14.7
checking ruby version... 1.9.2
checking for graph... no
checking for narray.h... yes
checking for main() in -lnarray... no
checking for tamu_anova/tamu_anova.h... no
checking for main() in -ltamuanova... no
creating Makefile
make
C:/Ruby192/bin/ruby -e "puts 'EXPORTS', 'Init_rb_gsl'" > rb_gsl-i386-mingw32.de
f
gcc -I. -IC:/Ruby192/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby192/include/ruby-1
.9.1/ruby/backward -I/C/Ruby192/include/ruby-1.9.1 -I. -DHAVE_NARRAY_H -IC:/Rub
y192/lib/ruby/gems/1.9.1/gems/narray-0.5.9.9/. -IC:/Ruby192/lib/ruby/site_ruby/1
.9.1/i386-msvcrt -Wall -I../include -I/usr/include -o alf.o -c alf.c
gcc -I. -IC:/Ruby192/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby192/include/ruby-1
.9.1/ruby/backward -I/C/Ruby192/include/ruby-1.9.1 -I. -DHAVE_NARRAY_H -IC:/Rub
y192/lib/ruby/gems/1.9.1/gems/narray-0.5.9.9/. -IC:/Ruby192/lib/ruby/site_ruby/1
.9.1/i386-msvcrt -Wall -I../include -I/usr/include -o array.o -c array.c
In file included from array.c:14:0:
../include/rb_gsl_common.h:18:27: fatal error: gsl/gsl_errno.h: No such file or
directory
compilation terminated.
make: *** [array.o] Error 1
Gem files will remain installed in C:/Ruby192/lib/ruby/gems/1.9.1/gems/gsl-1.14.
7 for inspection.
Results logged to C:/Ruby192/lib/ruby/gems/1.9.1/gems/gsl-1.14.7/ext/gem_make.ou
t
I have checked and I can find gsl_errno.h at /usr/include/gsl

Try supplying the path for the GSL includes on the command line when installing the gem.
gem install gsl -- --with-gsl-include-path=/usr/include/gsl

Related

fatal error: omp.h: No such file or directory using arm-unknown-linux-uclibcgnueabi (crosstool-ng)

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

Issues installing yaml for lua with luarocks during the c-compile

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.

"error: conflicting types for ‘sem_t’" when compiling eglibc-2.19 on Ubuntu

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.

make error: Building 64-bit GSL in Cygwin

Continuing from here, I am trying to build 64-bit GSL using GCC in Cygwin.
The call to ./configure (CC=x86_64-w64-mingw32-gcc CFLAGS=-m64 ./configure) goes through fine, but the call to make install results, after a whole load of folders are successfully processed, in
./.libs/libgslsiman.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
Makefile:326: recipe for target `siman_tsp.exe' failed
The full call that caused this was
Making all in siman
make2: Entering directory `/cygdrive/f/programming/c/libraries/gslCompiled/gsl-1.15/siman'
/bin/sh ../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -m64 -o siman_tsp.exe siman_tsp.o libgslsiman.la ../rng/libgslrng.la ../ieee-utils/libgslieeeutils.la ../err/libgslerr.la ../sys/libgslsys.la ../utils/libutils.la -lm
libtool: link: x86_64-w64-mingw32-gcc -m64 -o .libs/siman_tsp.exe siman_tsp.o ./.libs/libgslsiman.a ../rng/.libs/libgslrng.a ../ieee-utils/.libs/libgslieeeutils.a ../err/.libs/libgslerr.a ../sys/.libs/libgslsys.a ../utils/.libs/libutils.a
Following advice here, I decided to run a ranlib in the ./siman/.libs directory on the libgslsiman.a file. Since that didn't work, I also tried to pack it myself using a call to ar -t libgslsiman.a.
However, this results in an identical error.
You manually forced use of the cross compiler. However, the rest of the build toolchain will still default to the 32-bit Cygwin versions instead of the 64-bit MinGW ones.
Instead of setting CC=..., pass --host x86_64-w64-mingw32 to ./configure to specify the host environment (ie where the library is going to be used).

Nokogiri Compilation Error - Can't find libraries/headers

Trying to install a gem, but it can't find the headers, despite specifying them:
sudo gem install nokogiri -- --with-xml2-lib=/usr/local/lib --with-xml2-include=/usr/local/include/libxml2 --with-xml2-include=/usr/local/include/libxml2 --with-xslt-include=/usr/local/include/libxslt
Building native extensions. This could take a while...
ERROR: Error installing nokogiri:
ERROR: Failed to build gem native extension.
/usr/bin/ruby extconf.rb --with-xml2-lib=/usr/local/lib --with-xml2-include=/usr/local/include/libxml2 --with-xml2-include=/usr/local/include/libxml2 --with-xslt-include=/usr/local/include/libxslt
checking for #include <libxml/parser.h>
... no
-----
libxml2 is missing. please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.
The /usr/local/include/libxml2/libxml/parser.h file does exist, so I don't see why this isn't working.
EDIT: I'm on Centos 5.4
If you dig into /usr/lib/ruby/1.8/mkmf.rb you can figure out how to simulate the check that's happening during install. In my case I could do this by creating a file called conftest.c containing:
#include <libxml/parser.h>
Then try running the command that gets passed into the try_do function. In my case this was:
gcc -E -I. -I/usr/lib64/ruby/1.8/x86_64-linux -I. -I-I-I/opt/local/include -I-I-I/usr/local/include -I-I-I/usr/include -I-I-I/usr/include -I-I-I/usr/include/libxml2 -I/opt/local/include/libxml2 -I/usr/local/include/libxml2 -I-I/opt/local/include -I-I/usr/local/include -I-I/usr/include -I-I/usr/include -I-I/usr/include/libxml2 -I/opt/local/include -I/usr/local/include -I/usr/include -I/usr/include -I/usr/include/libxml2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -fPIC -g -DXP_UNIX -O3 -Wall -Wcast-qual -Wwrite-strings -Wconversion -Wmissing-noreturn -Winline conftest.c -o conftest.i
In my case I was missing gcc, which is probably not what you're hitting since you said you compiled from source. But hopefully if you run this command it should give you an idea of why you can't load in libxml2.
If you're interested in pre-built apparently EPEL has a rubygems-nokogiri package. Good chance I'll go this route in the end.

Resources