I am trying to compile a piece of code on my Linux system (x86_64) for MIPS big endian architecture.
Basically I followed this URL:
https://www.linux-mips.org/wiki/Toolchains
to get my own tool chain.
I tried to compile software, configure phase is OK:
./configure --target=mips-unknown-linux-gnu --host=mips-unknown-linux-gnu CC=/opt/cross/bin/mips-unknown-linux-gnu-gcc --prefix=/opt/mycode
I get this error just after "make":
# make
make all-recursive
make[1]: Entering directory `/usr/local/src/code2.0.9'
Making all in compat
make[2]: Entering directory `/usr/local/src/code2.0.9/compat'
/opt/cross/bin/mips-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -Wall -O2 -MT Thread.o -MD -MP -MF .deps/Thread.Tpo -c -o Thread.o Thread.c
In file included from Thread.c:71:0:
../include/headers.h:78:20: fatal error: stdlib.h: No such file or directory
#include <stdlib.h>
How can I fix this issue?
Thank you
I finally solved with buildroot.
I set target mips and build my toolchain.
After that, I used this command to compile source:
./configure --enable-static --disable-shared --target=mips-buildroot-linux-gnu --host=mips-buildroot-linux-gnu CC=/home/myuser/buildroot-2019.05.1/output/host/bin/mips-linux-gcc --with-openssl=no --disable-profiling
All went ok
I think host command is not correct.
try this,
./configure --target=mips-unknown-linux-gnu --host=linux CC=/opt/cross/bin/mips-unknown-linux-gnu-gcc --prefix=/opt/mycode
Related
I'm working on a Linux project in C consisting of two different open source applications. "Project A" (libduo) creates an archive used for linking a couple test programs and creates the library like this:
/usr/bin/ar rv libduo.a duo.o http_parser.o https.o match.o parson.o urlenc.o
/usr/bin/ar: creating libduo.a
a - duo.o
a - http_parser.o
a - https.o
a - match.o
a - parson.o
a - urlenc.o
ranlib libduo.a
One of the libduo test programs is built like this:
gcc -g -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -I. -I. -DDUODIR=\"/usr/local/duo/libduo/etc\" -DHAVE_CONFIG_H -c test-duologin.c
gcc -o test-duologin test-duologin.o -L. -lduo -lssl -lcrypto
"Project B" is an OpenLDAP module which I've built with -lduo and a few options to tell it where to find things:
(cd .libs && rm -f pw-apr1.la && ln -s ../pw-apr1.la pw-apr1.la)
../../../libtool --mode=compile gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -fPIC -DPIC -o .libs/pw-duo.o
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -o pw-duo.o >/dev/null 2>&1
../../../libtool --mode=link gcc -g -O2 -Wall -version-info 0:0:0 \
-rpath /usr/local/libexec/openldap -module -o pw-duo.la pw-duo.lo libduo.a -lduo
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
cc -shared .libs/pw-duo.o libduo.a -lduo -Wl,-soname -Wl,pw-duo.so.0 -o .libs/pw-duo.so.0.0.0
/usr/bin/ld: libduo.a(duo.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
libduo.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:51: recipe for target 'pw-duo.la' failed
make: *** [pw-duo.la] Error 1
The Makefile I'm using is the same one distributed with the OpenLDAP project. I've just added a section in the Makefile to build my module, using the same options for the other modules already there but adding -lduo to my section along with the paths to the libduo includes and libduo.a.
As make suggests above, I've recompiled by adding -fPIC after the -Wall option but it the same error was repeated. As a last resort, I tried adding -static to the module build but make was having none of that either:
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
This is the first time I've tried to build a C application against a lib not in the standard Linux locations so not exactly sure what's going on. I suspect libduo is built intended to be statically linked into everything, but the OpenLDAP modules are designed to use shared libraries. Can anyone elucidate?
Update: with help of comments below and this link I created a shared library from the .o files and distributed/built against that.
I am trying to use argon2 for C. I cloned the repo and tried to build it myself by typing make in the root directory of the repo. However, make threw this error:
Building without optimizations
cc -std=c89 -O3 -Wall -g -Iinclude -Isrc -pthread src/argon2.c src/core.c
src/blake2/blake2b.c src/thread.c src/encoding.c src/ref.c src/run.c -o argon2
process_begin: CreateProcess(NULL, cc -std=c89 -O3 -Wall -g -Iinclude -Isrc -
pthread src/argon2.c src/core.c src/blake2/blake2b.c src/thread.c
src/encoding.c src/ref.c src/run.c -o argon2, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [argon2] Error 2
I referred to this stack overflow post and I think I am getting this error because I do not have 'cc' installed. What is 'cc' and am I correct about 'cc' needing to be installed? I am on windows by the way. I know this is a super specific question but maybe someone can help me.
I've been having trouble debugging some C code that I'm writing as part of an R package. The code compiles and executes when I use R CMD SHLIB from the Windows console (i.e. cmd.exe):
>R CMD SHLIB MaximumAgreementForest.c
gcc -m64 -I"C:/PROGRA~1/R/R-32~1.4RE/include" -DNDEBUG -I"d:/RCompile/r-compiling/local/local323/include" -O2 -Wall -std=gnu99 -mtune=core2 -c MaximumAgreementForest.c -o MaximumAgreementForest.o
gcc -m64 -shared -s -static-libgcc -o MaximumAgreementForest.dll tmp.def MaximumAgreementForest.o -Ld:/RCompile/r-compiling/local/local323/lib/x64 -Ld:/RCompile/r-compiling/local/local323/lib -LC:/PROGRA~1/R/R-32~1.4RE/bin/x64 -lR
The script also built correctly in Netbeans until I started using the functions R_alloc and C_alloc from the R libraries. Now it doesn't seem to be able to find the definitions of a number of R-specific functions. When I attempt to build the project in Netbeans the console lists the following:
cd 'C:\Work\Fun\implied_weight\MAF'
C:\MinGW\msys\1.0\bin\make.exe -f Makefile CONF=Debug
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make.exe[1]: Entering directory `/c/Work/Fun/implied_weight/MAF'
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk dist/Debug/MinGW-Windows/libMAF.dll
make.exe[2]: Entering directory `/c/Work/Fun/implied_weight/MAF'
mkdir -p build/Debug/MinGW-Windows/_ext/5c0
rm -f "build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o.d"
gcc -DDEBUG -O2 -Wall -mtune=core2 -c -g -Wall -I/C/Program\ Files/R/R-3.2.4revised/include -MMD -MP -MF "build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o.d" -o build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o ../MaximumAgreementForest.c
mkdir -p dist/Debug/MinGW-Windows
gcc -DDEBUG -O2 -Wall -mtune=core2 -o dist/Debug/MinGW-Windows/libMAF.dll build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o -L/C/Program\ Files/R -L/C/Program\ Files/R/R-3.2.4revised/library -shared
build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o: In function `forest_new':
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:37: undefined reference to `R_alloc'
build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o: In function `forest_plant':
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:55: undefined reference to `S_alloc'
[...]
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:515: undefined reference to `R_chk_free'
collect2.exe: error: ld returned 1 exit status
My script, a single .c file, contains the lines
#define USE_RINTERNALS
#include <R.h> // which itself #includes R_ext/Memory, R_ext Printf
#include <R_ext/Print.h>
#include <R_ext/Memory.h>
#include <Rinternals.h>
Figuring that Netbeans is failing to point to the relevant libraries, I have tried adding and removing C:/Program Files/R/R-3.2.4revised/include and C:/Program Files/R/R-3.2.4revised/bin/x64 at File→Project Properties→General→Source folders, to no effect.
Under File→Project Properties→Build→C compiler, I have included C:/Program Files/R/R-3.2.4revised/include.
When I add C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll to Build→Linker→Libraries→Libraries, via the Add Library... option, I receive the error c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lR, and the linker exits without (before?) complaining about the undefined references.
When I subsequently add "C:/Program Files/R/R-3.2.4revised/bin/x64/", which is already in by System PATH, to Build→Linker→Additional Library Directories, the compiler fails with the message C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll: file not recognized: File format not recognized
What am I missing... how can I point Netbeans to the relevant R libraries?
The File format not recognized error is encountered when a 32-bit compiler tries to load to a 64-bit .dll (or vice-versa). Changing the path
C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll
to
C:/Program Files/R/R-3.2.4revised/bin/i386/R.dll
resolved the problem.
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 have been trying to compile xalan-c specifically 1.11 with xerces 3.1.1. with an arm cross-compile toolchain 4.3.3 from CodeSourcery on a ubuntu 14.x 64.
xalan-c has two configure scripts. First the usual ./configure and second ./runConfigure.
Up until now I have been cross-compiling other libs (e.g. libusb-1.0/libusb-0.1/openssl) with
--host../configure --host=arm-none-linux-gnueabi --prefix="/home/user/sysroot-arm-sf/usr/local/"
This time however I believe I need to use ./runConfigure otherwise some environment variables are not set (e.g. how it deals with messages)
I use:
./runConfigure -p linux -x arm-none-linux-gnueabi-g++ -c arm-none-linux-gnueabi-gcc -P "/home/user/sysroot-arm-sf/usr/local/" -C--host=arm-none-linux-gnueabi
instead which I believe to be the equivalent to ./configure . the ./runConfigure is using all default values (except for the c and c++ compiler which it does not recognize, unfortunately)
Generating makefiles with the following options ...
Platform: linux
C Compiler: arm-none-linux-gnueabi-gcc
C++ Compiler: arm-none-linux-gnueabi-g++
Extra compile options:
Extra link options:
Transcoder: default
Localization system: inmem
Locale: en_US
Thread option: pthread
bitsToBuild option: 32
Extra configure options: --prefix=/home/user/sysroot-arm-sf/usr/local/ --host=arm-none-linux-gnueabi
Debug is OFF
I do not recognize the C compiler 'arm-none-linux-gnueabi-gcc'. Continuing anyway ...
I do not recognize the C++ compiler 'arm-none-linux-gnueabi-g++'. Continuing anyway ...
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for arm-none-linux-gnueabi-gcc... arm-none-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-none-linux-gnueabi-gcc accepts -g... yes
checking for arm-none-linux-gnueabi-gcc option to accept ANSI C... none needed
checking for arm-none-linux-gnueabi-g++... arm-none-linux-gnueabi-g++
checking whether we are using the GNU C++ compiler... yes
checking whether arm-none-linux-gnueabi-g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for autoconf... autoconf
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-none-linux-gnueabi
checking for floor in -lm... yes
checking how to run the C++ preprocessor... arm-none-linux-gnueabi-g++ -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for mbstowcs... yes
checking if mbstowcs can count only... cross-compiling default
configure: creating ./config.status
config.status: creating Makefile.incl
config.status: creating Makefile
config.status: creating src/xalanc/Makefile
config.status: creating src/xalanc/Utils/Makefile
config.status: creating src/xalanc/Utils/MsgCreator/Makefile
config.status: creating src/xalanc/Utils/XalanMsgLib/Makefile
config.status: creating samples/Makefile
config.status: creating Tests/Makefile
If the result of the above commands look OK to you, go to the directory
/home/user/xalan-c-1.11/c/ and type "gmake" or "make" to make the XALAN-C system.
Note: You must use GNU make to use the Xalan Makefile.
Then I'll try
make
make -C src/xalanc all
make[1]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc'
Preparing the directory structure for a build ...
mkdir -p ../../obj
mkdir -p ../../lib
mkdir -p ../../bin
make -C Utils prepare
make[2]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
mkdir -p ../../../nls
mkdir -p ../../../nls/include
make[2]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
make -C Utils locale
make[2]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
make -C MsgCreator
make[3]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils/MsgCreator'
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/MsgFileOutputStream.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/MsgFileOutputStream.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/ICUResHandler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/ICUResHandler.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/InMemHandler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/InMemHandler.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/MsgCreator.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/MsgCreator.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/NLSHandler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/NLSHandler.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/SAX2Handler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/SAX2Handler.cpp
arm-none-linux-gnueabi-g++ -DLINUX -fPIC -pthread -D_REENTRANT -DXALAN_INMEM_MSG_LOADER \
-lm -lpthread ../../../../obj/MsgFileOutputStream.o ../../../../obj/ICUResHandler.o ../../../../obj/InMemHandler.o ../../../../obj/MsgCreator.o ../../../../obj/NLSHandler.o ../../../../obj/SAX2Handler.o -o ../../../../bin/MsgCreator -L/home/user/xerces-c-3.1.1//lib -lxerces-c
make[3]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils/MsgCreator'
../../../bin/MsgCreator /home/user/xalan-c-1.11/c//src/xalanc/NLS/en_US/XalanMsg_en_US.xlf -TYPE inmem -LOCALE en_US
../../../bin/MsgCreator: ../../../bin/MsgCreator: cannot execute binary file
make[2]: *** [../../../nls/include/LocalMsgData.hpp] Error 126
make[2]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
make[1]: *** [locale] Error 2
make[1]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc'
make: *** [all] Error 2
and it will fail executing
../../../bin/MsgCreator /home/user/xalan-c-1.11/c//src/xalanc/NLS/en_US/XalanMsg_en_US.xlf -TYPE inmem -LOCALE en_US
which is
bin/MsgCreator: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
a binary for an Arm arch. I though ./runConfigure had used the --host option and was aware this was a cross build. Or maybe this is something xalan-c specific?
It does say
checking whether we are cross compiling... yes
So this looks like a poorly tested makefile, to me.
You could try to debug it, or you could just install qemu so that ARM binaries magically Just Work (assuming they can find their libraries).
I tried the following workaround which apparently worked.
The files in the xalanc bin/ Folder seem to be only used at compile time (at least I guessed so). Xalan generates headerfiles etc. in order to compile the libxalanMsg.so .
It was a long shot but I simply precompile those bin/ files for Ubuntu x86 and copied those files into my cross compile bin folder.
done. (at least for now)
This problem is really tough and weird. Fortunately, I find a way to resolve this problem.
From the error, we can conclude that the build process uses an executable tool named 'MsgCreator'.
Where is it from?
Actually, this tool is an intermediate product of the build process. Xalan generate it and use this tool to do something he wants.
What happens?
You may remember that you are now cross-compiling Xalan, so the target executable platform of MsgCreator may not support your build platform. This case will cause the error you see.
How to solve this problem
Use the local compiler to build a local MsgCreator which means this tool can run on your build platform.
Update the code in …./xalan-c-1.11/c/src/xalanc/Utils/MsgCreator/Malefile.in.
$(XSL_BIN_DIR)/MsgCreator -> $(XSL_BIN_TMP_DIR)/MsgCreator
Export XSL_BIN_TMP_DIR to your local MsgCreator tool path.
export LD_LIBRARY_PATH to add MsgCreator dependency libraries. These libraries can be generated by compiling Xerces-C (the version must greater than 3.0) with your local compiler.
Cross compile Xalan, everything will go well.