I've cloned the LuaJIT git repo and built it with:
make STATIC_CC="musl-gcc" BUILDMODE="static"
Then, I compiled a simple Lua "hello world" script into a C header file:
luajit -b test.lua test.h
test.h:
#define luaJIT_BC_test_SIZE 52
static const unsigned char luaJIT_BC_test[] = {
27,76,74,2,10,45,2,0,3,0,2,0,4,54,0,0,0,39,2,1,0,66,0,2,1,75,0,1,0,20,72,101,
108,108,111,32,102,114,111,109,32,76,117,97,33,10,112,114,105,110,116,0
};
After that, I wrote a simple C wrapper by following the official example, test.c:
#include <stdio.h>
#include <lua.h>
#include <lualib.h>
#include <lauxlib.h>
#include "test.h"
int main(void) {
int error;
lua_State *L = lua_open();
luaL_openlibs(L);
error = luaL_loadbuffer(L, (const char *) luaJIT_BC_test, luaJIT_BC_test_SIZE, "test") || lua_pcall(L, 0, 0, 0);
if (error) {
fprintf(stderr, "%s", lua_tostring(L, -1));
lua_pop(L, 1);
}
lua_close(L);
return 0;
}
But when I try to build it, it crashes with an error:
$ musl-gcc -static -ILuaJIT/src -LLuaJIT/src -o test test.c -lluajit
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE':
(.text+0x1953): undefined reference to `_dl_find_object'
collect2: error: ld returned 1 exit status
It's related to libgcc, so I tried building everything with musl-clang, but still got the same error. Can someone explain what I'm missing here?
Figured it out - I needed to build LuaJIT with TARGET_XCFLAGS=-DLUAJIT_NO_UNWIND like so:
make STATIC_CC="musl-gcc" BUILDMODE="static" TARGET_XCFLAGS=-DLUAJIT_NO_UNWIND
I guess this just disables C++ exceptions support, but I'm not sure what the real implications are. Seems to work fine, for now.
The following code sample is compiled with the subsequent command line input
#include <pthread.h>
#include <stdio.h>
#include <string>
#include <map>
typedef std::map<std::string, std::string> map_t;
void *threadfunc(void *p) {
map_t& m = *(map_t*)p;
m["foo"] = "bar";
return 0;
}
int main() {
map_t m;
pthread_t t;
pthread_create(&t, 0, threadfunc, &m);
printf("foo=%s\n", m["foo"].c_str());
pthread_join(t, 0);
}
Command line input:
g++ thread.cpp -fsanitize=thread -fPIE -pie -lpie -g
It compiles fine, but when the code is run there are runtime errors.
FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x56167ae3b000 < 0x7cf000000000)
FATAL: Make sure to compile with -fPIE and to link with -pie.
I am running this with a version of g++ that has fSanitize so I am unsure about where the source of the problem is?
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
GCC is too old for Linux kernel used in your RedHat. Due to the mapped address 0x56167ae3b000 I guess the kernel version is 4.1+ (or backported from the kernel version 4.1+) that maps binaries at 0x550000000000. This mapped address is supported by GCC starting from the version 7.1.1. Please try to add the compiler flag -static-libtsan. If it does not help then you need to upgrade your compiler.
I recently moved from Ubuntu 14.04 to Ubuntu 16.04 for working on code. This moved me from GCC 4.8.4/GNU ld 2.24 to GCC 5.3.1/GNU ld 2.26.
I've been writing test cases for code and someone decided to override the default time() function for testing but linking behavior seems to have changed between these two releases. Example code follows:
nothing.c:
#include <stdio.h>
#include <time.h>
void nothing( )
{
printf( "%lld\n", (long long)time( NULL ) );
}
something.c:
#include <stdio.h>
#include <time.h>
extern void nothing( void );
int main( )
{
printf( "%lld\n", (long long)time( NULL ) );
nothing( );
return 0;
}
faketime.c:
#include <time.h>
time_t time( time_t * ptr )
{
return 42;
}
Now, if I compile this code using the following:
gcc -fPIC -c -o nothing.lo nothing.c
gcc -shared -rdynamic -o libnothing.so nothing.lo
gcc -o something something.c faketime.c -Wl,-rpath=. -L. -lnothing
I get two different results on each of the environments upon which I attempt to run the executable.
Ubuntu 14.04 says the answer is "42/42" while Ubuntu 16.04 says the answer is "42/1464287587" (insert your current Unix timestamp).
I'm curious if this is a conscious change or whether I am doing something wrong here? I sort of assume the "new way" is actually more correct as it seems like a loophole for me to override a system call a library expects to make. However, maybe that's normal and maybe now this method of "linker substitution" is broken in the new compiler/linker?
Why am I not able to compile my code to c++ 11 and use the srand48 function?
I have a program where I play around with some matrices.
The problem is that when I compile the code with the -std=c++0x flag.
I want to use some c++11 only functions and this is my approach to do so.
It compiles without any problems if I do not specify the c++ version. Like this:
g++ -O2 -Wall test.cpp -o test -g
Please correct me if I have misunderstood what the mentioned flag does.
I run my code on a Windows 7 64-bit machine and compile through cygwin. I use g++ version 4.5.3 (GCC). Please comment if more information is required.
For some unknown reason (even to myself) then all my code is written in one compilation unit.
If the error is caused by a structural error then you should also feel free to point it out. :)
I receive the following errors:
g++ -std=c++0x -O2 -Wall test.cpp -o test -g
test.cpp: In function ‘void gen_mat(T*, size_t)’:
test.cpp:28:16: error: there are no arguments to ‘srand48’ that depend on a template parameter, so a declaration of ‘srand48’ must be available
test.cpp:28:16: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
test.cpp:33:28: error: there are no arguments to ‘drand48’ that depend on a template parameter, so a declaration of ‘drand48’ must be available
Here is a sub of my code, it generates the errors shown above.
#include <iostream>
#include <cstdlib>
#include <cassert>
#include <cstring>
#include <limits.h>
#include <math.h>
#define RANGE(S) (S)
// Precision for checking identity.
#define PRECISION 1e-10
using namespace std;
template <typename T>
void gen_mat(T *a, size_t dim)
{
srand48(dim);
for(size_t i = 0; i < dim; ++i)
{
for(size_t j = 0; j < dim; ++j)
{
T z = (drand48() - 0.5)*RANGE(dim);
a[i*dim+j] = (z < 10*PRECISION && z > -10*PRECISION) ? 0.0 : z;
}
}
}
int main(int argc, char *argv[])
{
}
Regards Kim.
This is the solution that solved the problem for me:
First n.m. explained that srand() can not be used when compiling with -std=c++0x.
The correct flag to use is -std=gnu++11 however it require g++ version 4.7+
Therefore, the solution for me was to compile my code with -std=gnu++0x
The compile command = g++ -O2 -Wall test.cpp -o test -g -std=gnu++0x
If you explicitly set -stc=c++03 you will get the same error. This is because drand48 and friends are not actually a part of any C++ standard. gcc includes these functions as an extension, and disables them if standard behaviour is requested.
The default standard mode of g++ is actually -std=gnu++03. You may want to use -std=gnu++11 instead of -std=c++0x, or pass -U__STRICT_ANSI__ to the compiler.
Here is my test program:
#include <stdio.h>
#pragma GCC diagnostic ignored "-Wcast-qual"
static void proc(char *buf)
{
printf("buf=%p\n",buf);
}
int main(int argc,char **argv)
{
const char *cbuf;
char *buf = (char *)cbuf;
proc(buf);
return(0);
}
Here is my compile:
$ g++ -Wcast-qual x.cpp
x.cpp: In function ‘int main(int, char**)’:
x.cpp:13: warning: cast from type ‘const char*’ to type ‘char*’ casts away constness
$
And here is the compile without the -Wcast-qual:
$ g++ x.cpp
$
I've used #pragma GCC diagnostic ignored in other places of my code without problems. Here it is not working. Can somebody tell me why?
It's a compiler bug on the Mac. GCC 4.7.2 on Linux does not have this problem. Neither does clang++. On the Mac you should try to use clang++, not g++.
Apple should update its compiler.