I am trying to compile an Octave nsi-installer for Windows with --enable-64 for large array support.
Attempt 1: Using a Linux Mint virtual machine on Windows 10:
./configure shows everything seems to be OK, and after running make, quite a lot completes. However, several minutes into "[build] default-octave", it crashes out. Looking at the log, when trying to link liboctave/.libs/liboctave-3.dll, it says:
libgnu/.libs/libgnu.a(lock.o): In function glthread_recursive_lock_init_multithreaded':
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/glthread/lock.c:289: undefined reference to__imp_pthread_mutexattr_init'
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/glthread/lock.c:292: undefined reference to __imp_pthread_mutexattr_settype'
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/glthread/lock.c:298: undefined reference to__imp_pthread_mutex_init'
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/glthread/lock.c:304: undefined reference to __imp_pthread_mutexattr_destroy'
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/glthread/lock.c:301: undefined reference to__imp_pthread_mutexattr_destroy'
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/glthread/lock.c:295: undefined reference to __imp_pthread_mutexattr_destroy'
libgnu/.libs/libgnu.a(strsignal.o): In functioninit':
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/strsignal.c:143: undefined reference to __imp_pthread_key_create'
libgnu/.libs/libgnu.a(strsignal.o): In functionfree_key_mem':
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/strsignal.c:170: undefined reference to __imp_pthread_setspecific'
libgnu/.libs/libgnu.a(strsignal.o): In functionstrsignal':
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/strsignal.c:101: undefined reference to __imp_pthread_once'
libgnu/.libs/libgnu.a(strsignal.o): In functiongetbuffer':
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/strsignal.c:186: undefined reference to __imp_pthread_getspecific'
/home/mike/temp/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libgnu/strsignal.c:195: undefined reference to__imp_pthread_setspecific'
collect2: error: ld returned 1 exit status
So, the problem is all these undefined references to '__imp_pthread_' functions in lock.c.
When I look at lock.c at those lines, the code shows:
err = pthread_mutexattr_init (&attributes);
So my main question is, why in linking is '__imp_' added to the front of the function?
If I 'nm libpthread.so', I see stuff like:
pthread_mutexattr_init.o:
0000000000000000 T __pthread_mutexattr_init
0000000000000000 T pthread_mutexattr_init
So the functions are in there, but the link doesn't see them because the '__imp_' is attached? I don't understand...
The log shows that '-pthread' is used rather than '-lpthread', which I think is what is recommended. When I look at the top of the log, it shows:
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
Attempt 2: Using a CentOS linux system:
Similar to above, ./configure works but a little ways into "[build] default-octave", it crashes out. Looking at the log, it says:
/u/glaucus-r1/mpjohnso/octave/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/liboctave/array/dim-vector.h: In instantiation of 'dim_vector::dim_vector(octave_idx_type, octave_idx_type, Ints ...) [with Ints = {int}; octave_idx_type = long long int]':
/u/glaucus-r1/mpjohnso/octave/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/libinterp/octave-value/ov-typeinfo.h:203:85: required from here
/u/glaucus-r1/mpjohnso/octave/mxe-octave-3fc30cd416ac/tmp-default-octave/octave-4.1.0+/liboctave/array/dim-vector.h:215:5: error: unable to deduce std::initializer_list<_Tp>&&' from '{r, c, lengths#0}'
for (const auto l: {r, c, lengths...})
^
So, there seems to be some problem with how the '{r, c, lengths...}' line is interpreted... My first try used GCC 4.4.7, but the same thing happened once upgrading to GCC 6.2.0.
Any thoughts for either?
Related
I am attempting to set up cross-compiling for a cross-platform, open source computer game (Simutrans-Experimental: a fork of Simutrans).
It uses the pthreads multi-threading library. At one part of the code, my fork (but not the original version) uses the pthread_cleanup_push() and pthread_cleanup_pop() functions.
When I attempted to cross-compile this (for 32-bit Windows using MinGW32), I got the following compiler error:
error: second operand to the conditional operator is of type âvoidâ, but the third operand is neither a throw-expression nor of type âvoidâ
pthread_cleanup_pop(1);
(And a similar error for the "push" equivalent).
I was advised by one of the developers of the standard version of Simutrans to modify a part of pthread.h to
#define pthread_cleanup_pop(E)\
(*pthread_getclean() = _pthread_cup.next, ((E) ? (_pthread_cup.func((pthread_once_t *)_pthread_cup.arg)) : (void)0));}
This then allowed the code to compile.
However, I now get linker errors relating to the same part of the code:
===> LD build/mingw/simutrans-experimental
build/mingw/simworld.o:simworld.cc:(.text+0x1914): undefined reference to _imp__ptw32_push_cleanup'
build/mingw/simworld.o:simworld.cc:(.text+0x198b): undefined reference to_imp__ptw32_pop_cleanup'
collect2: error: ld returned 1 exit status
common.mk:21: recipe for target 'build/mingw/simutrans-experimental' failed
I do not understand what is happening here, or why the pthreads that comes with mingw does not work with one of the fundamental parts of the pthreads library.
Can anyone assist? I should be very grateful.
I am trying to build some code with G++4.8. Operating system is FreeBSD 9.2 64-bit.
These are the errors I get:
/usr/local/lib/gcc48/include/c++/tr1/hashtable_policy.h:384: undefined reference to `std::tr1::__detail::__prime_list'
/usr/local/lib/gcc48/include/c++/bits/stl_list.h:1570: undefined reference to `std::__detail::_List_node_base::_M_unhook()'
/usr/local/lib/gcc48/include/c++/bits/stl_list.h:1562: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
I read somewhere that those functions are in libstdc++. Reading this I've added that lib at my project, but I still get those errors. I should add libstdg++ instead? Or it's something else? I don't get it.
I've got the same errors when I linked the program using cc instead of gcc because of a misconfiguration of the Makefile program.
I am trying to compile a fortran code which was last compiled in early 90's on Windows machine using Lahey Fortran . Now, I am compiling with gfortran on ubuntu 64x.
I am getting following error
$ gfortran 3RINGS.FOR
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xc10): undefined reference to _mmbsk0_'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xc3d): undefined reference tommbsk1'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xc6a): undefined reference to _mmbsi0_'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xc97): undefined reference tommbsi1'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xcc4): undefined reference to _mmbsk0_'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xcf1): undefined reference tommbsk1'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xd1e): undefined reference to _mmbsi0_'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0xd4b): undefined reference tommbsi1'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0x1182): undefined reference to _mmbsk0_'
/tmp/ccjCDh8B.o:3RINGS.FOR:(.text+0x11a5): undefined reference tommbsi0'
collect2: ld returned 1 exit status
The error is regarding following variable declaration in code
REAL*8 MMBSK0,MMBSK1,MMBSI0,MMBSI1
I will appreciate any suggestion to solve this problem and compile this code.
I will be happy to upload the entire code (263 lines) if anybody need that.
(Unrelated to your problem - note that REAL*8 is an extension to standard Fortran. The correct syntax is REAL(8), where the meaning of "8" depends on your compiler.)
The compiler thinks those MM... names declare functions, rather than variables. It usually deduces that a name references a function based on the way the name is used later in the code.
I'd guess that there's more to your program than the single source file - perhaps other source files that you need to compile and link in with your main program.
I developed an application for an ARM7 embedded system in C. Now I want to compile and link it with C++ in order to use some C++ features. To do this, I am using mipsel-elf-g++ instead of mipsel-elf-gcc. I can compile my code with mipsel-elf-g++ successfully, but in linking step I get the errors:
/opt/mipsel/lib/gcc/mipsel-elf/3.4.6/../../../../mipsel-elf/lib/libc.a(lib_a-abort.o): In function```abort':
/cygdrive/d/Files/cross/mips/newlib-1.15.0/newlib/libc/stdlib/abort.c:63: undefined reference to_exit'`
/opt/mipsel/lib/gcc/mipsel-elf/3.4.6/../../../../mipsel-elf/lib/libc.a(lib_a-signalr.o): In function```_kill_r':
/cygdrive/d/Files/cross/mips/newlib-1.15.0/newlib/libc/reent/signalr.c:61: undefined reference tokill'`
collect2: ld returned 1 exit status
I searched about this issue and found that I should implement my own _exit and kill functions, so I added this codes to my project:
void _exit(int code)
{
while(1);
}
int _DEFUN (kill, (pid, sig), int pid _AND int sig)
{
if(pid == __MYPID)
_exit(sig);
return 0;
}
By adding these two functions, the undefined reference to `_exit' error is fixed, but the undefined reference to ``kill' error still exists.
What should I do to fix this issue?
Try wrapping the kill function in extern "C" { … }. And, for clarity, I suggest not using the _DEFUN macro.
I know this is an old question, but I ran against the same problem and found a solution. Add these options to your linker:
-specs=nano.specs -specs=nosys.specs -lnosys
I'm not sure, but the first thing, that I see is, that the parameter "kill" has no type...
But the only undefined reference errors I ever got were linking errors... so are there any libraries you forgot to link to?
I am getting a compile error trying to compile a simple tester program from the documentation.
C:\DOCUME~1\A\LOCALS~1\Temp\ccRsXzHu.o:tester.cpp:(.text+0xa6): undefined reference to `_imp___ZN5boost6thread4joinEv'
C:\DOCUME~1\A\LOCALS~1\Temp\ccRsXzHu.o:tester.cpp:(.text+0xb4): undefined reference to `_imp___ZN5boost6threadD1Ev'
C:\DOCUME~1\A\LOCALS~1\Temp\ccRsXzHu.o:tester.cpp:(.text+0xcf): undefined reference to `_imp___ZN5boost6threadD1Ev'
C:\DOCUME~1\A\LOCALS~1\Temp\ccRsXzHu.o:tester.cpp: (.text$_ZN5boost11this_thread18interruptible_waitEy[boost::this_thread::interruptible_wait( unsigned long long)]+0x4a): undefined reference to `_imp___ZN5boost11this_thread18interruptible_waitEPvNS_6detail7timeoutE'
C:\DOCUME~1\A\LOCALS~1\Temp\ccRsXzHu.o:tester.cpp: (.text$_ZN5boost6threadC1IPFvvEEET_NS_10disable_ifINS_14is_convertibleIRS4_NS_6detail13thre ad_move_tIS4_EEEEPNS0_5dummyEE4typeE[boost::thread::thread<void (*)()>(void (*)(), boost::disable_if<boost::is_convertible<void (*&)(), boost::detail::thread_move_t<void (*)()> >, boost::thread::dummy*>::type)]+0x23): undefined reference to `_imp___ZN5boost6thread12start_threadEv'
collect2: ld returned 1 exit status
I am using mingw 4.5 and g++ 4.5.2 on windows. Boost version v1.4.8.
I hope someone can help me solve this problem.
Thanks.
It looks like you aren't linking to the boost libraries.
Boost doesn't come with windows since it isn't a standard library. You've got to download the headers and libraries, then include the headers in your project and link to the libraries at compile time. Since you're using g++, this means adding a -l line to your compile command. The -l line must be used with each specific library you want to use also, you can't just specify the boost directory.
This page will help you get started on Windows and this page will help you get started on *nix platforms.
Once you've compiled boost, then in your example, you should compile your program with
g++ -o tester.exe -Lpath/to/boost/libraries/ -lboost_thread tester.c
Make sure you've got all your libraries linked properly.
Try putting this line first if your thread library is statically defined
#define BOOST_THREAD_USE_LIB
Also, check out this thread.