I'm trying to compile the following program inside of a docker container.
https://github.com/adaptivecomputing/torque
When attempting to run autoconf I am given an error "possibly undefined macro: AC_MSG_ERROR"
Google has dozens of results for this exact error. Most of them are solved by installing pkg-config or libtool-ltdl
As you can see from my docker file, both of those packages are installed.
FROM centos
RUN yum install -y autoconf make autogen gcc gcc-c++ openssl-devel git libxml2-devel libtool libtool-ltdl
RUN git clone git://github.com/adaptivecomputing/torque.git -b 4.2.6.1 /tmp/pbs_server
RUN cd /tmp/pbs_server
RUN autoconf
RUN ./configure --with-debug
RUN make -j4
RUN make install
Here is the error that I get when running docker build .
Step 4 : RUN autoconf
configure.ac:50: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:54: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.ac:57: error: possibly undefined macro: AM_PROG_CC_C_O
configure.ac:63: error: possibly undefined macro: AM_MAINTAINER_MODE
configure.ac:82: error: possibly undefined macro: AM_CONFIG_HEADER
configure.ac:144: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:644: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:651: error: possibly undefined macro: AM_PROG_LEX
configure.ac:2053: error: possibly undefined macro: AC_DECL_H_ERRNO
configure.ac:2056: error: possibly undefined macro: AC_DECL_FD_SET_SYS_SELECT_H
configure.ac:2138: error: possibly undefined macro: AC_C_BIGENDIAN_CROSS
configure.ac:2204: error: possibly undefined macro: AC_CREATE_GENERIC_CONFIG
I have no problems compiling this program outside of docker and inside a normal server. I suspect there is a library or something that is missing.
Can anyone explain why I am getting this error, or better yet, how to work around it?
As #BrettHale said, you'll need to install automake (I don't see in in the yum install line), as torque definitely uses it. And this:
RUN autoconf
probably should be:
RUN ./autogen.sh
It'll invoke autoconf, as well as other stuff. I still don't see why what you did seemed to die immediately. AC_MSG_ERROR, etc. are part of the base macros of autoconf. Almost like those macros are unreadable within docker...
You will need to install autoconf, automake, and libtool. And possibly pkgconfig. After that, run the autogen.sh script. The autotool scripts should now be in place, and you can configure the package.
Related
I recently change my OS to the last mint cinamon. Compiling one of the library I need (and that I used to used without problem), I get this message:
fatal error: Eigen/Core: No such file or directory compilation terminated.
I don't know what to do.
Thanks for the help.
Including directory /usr/local/include/eigen3/ solved this for me.
Like this, for example:
g++ -I/usr/local/include/eigen3/ CODE.cpp -o EXECUTABLE
Try to install eigen3 library,
on Ubuntu it would be
sudo apt-get install libeigen3-dev
I'm new in Go. I want to use PortMidi wrapper for Go, trying to use this:
Go PortMidi
When using:
go get github.com/rakyll/portmidi
I've got:
/usr/bin/ld: $WORK/github.com/rakyll/portmidi/_obj/portmidi.cgo2.o: undefined reference to symbol 'Pt_Start'
/usr/lib/libporttime.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Tried to search something about:
DSO missing from command line
And:
undefined reference to symbol 'Pt_Start'
But found nothing.
Repaired it.
Installing libportmidi0 from official repo is bad idea. Need to compile it, for example from:
PortMIDI source download
All the instructions how to compile it in directory pm_linux.
The dynamic library of libportmidi is missing.
Try:
sudo apt-get install libportmidi0
That should fix it if you're on a debian/ubuntu system. If the library is not available on your linux system search your can still get the library source and compile it yourself.
I have been writing some python extension modules with cython. The extensions I've written build and work well. Then, I wanted to use typed memoryviews, when accessing my numpy arrays, as they seem to have several advantages http://docs.cython.org/src/userguide/memoryviews.html
However, as soon as I use a memoryview in my cython code I will get an error when building the extension. For example, if I add this test line:
cdef double[:, ::1] X = np.zeros((100, 100))
to an existing, working cython extension. I will get the following errors:
C:\MinGW\bin\gcc.exe -shared -s build\temp.win32-2.7\Release\image_box.o build\temp.win32-2.7\Release\image_box.def -Lc:\python27\libs -Lc:\python27\PCbuild -lp
ython27 -lmsvcr90 -o x:\ARframework\python\image_ops\image_box.pyd
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0xe23): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x3318): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4c81): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4d37): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10767): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10793): undefined reference to `___sync_fetch_and_sub_4'
collect2.exe: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
I've tried to add -march=i486 to the gcc line, as suggested in this post:
undefined reference to sync_fetch_and_add_4
but that didn't solve the problem. For that matter, I also tried -march=i586 and -march=pentium without success.
Any idea what's going on here?
My platform is Windows 7, mingw version is 4.70, Cython version is 0.17.1
Thanks
I found a solution.
Actually, the gcc flag -march=i486 does solve the problem! However, when I tested it in the console I just applied it to the gcc line for the link step (that's where I got the errors) and as it didn't solve the problem I thought it just didn't work.
In fact, I need to use -march=i486 both in the compile and link steps, then there is no errors anymore.
As to how to include these flags when I build the extension, I have tried to add
import os
os.environ['LDFLAGS'] = '-march=i486'
os.environ['CFLAGS'] = '-march=i486'
to the setup.py but it didn't seem to work.
So I have modified the c:\python27\Lib\distutils\cygwinccompiler.py to include these flags in the compile and link steps. Not sure if this is very elegant way of setting these flags. Any alternatives are welcome!
I installed SFML from scratch today so I could work on a game. I downloaded the source, ran sudo make install, tried compiling one of my old projects, and I couldn't get it to link properly. So I tried running a simpler project: one of the samples in the tutorials. I tried to compile this one specifically, but I get these errors:
g++ -o atest test.cpp -lsfml-graphics -lsfml-window -lsfml-system /tmp/ccaa86fR.o: In function `main':
test.cpp:(.text+0x1d2): undefined reference to `gluPerspective'
collect2: ld returned 1 exit status
make: *** [test] Error 1
Trying an even simpler project, the one in the initial tutorial, I don't run into problems compiling. However, when I try to run it, I get this error:
./atest: error while loading shared libraries: libsfml-graphics.so.1.6: cannot open shared object file: No such file or directory
I checked, and the files did install to /usr/local/lib/ which is where they're supposed to go as far as I know. What am I doing wrong here?
-lGLU should fix the first error and for the second one make sure /usr/local/lib/ is in your ldconfig search path (/etc/ld.so.conf and /etc/ld.so.conf.d/* under Ubuntu) and that you ran ldconfig: sudo ldconfig -v then try running again.
see also man ldconfig
When compiling GCC it is possible to get very far in the build process only to hiccup on an error complaining about the lack of gperf installed. After installing gperf and running, I hit an "undefined reference to libc_name_p." I've looked at the solutions here and here but they weren't helpful.
When gperf wasn't installed, the compilation script ran the command anyway but generated a blank ./gcc/cp/cfns.h. Since this file was newer than the source (./gcc/cp/cfns.gperf) the makefile left it alone and never regenerated the 'real' file when you actually had gperf. To continue, run rm ./gcc/cp/cfns.h and try again.