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?
