I'm about done working out the dependencies for compiling a program on my linux box. I'm running Linux Mint 19 64bit. The last hurdle I can't seem to get over is a syntax error about a specific line in the configure shell script. Exact error is:
./configure: line 1804: syntax error near unexpected token [foreign]'
./configure: line 1804:AM_INIT_AUTOMAKE([foreign])'
The sister file configure.ac has a reference to AM_INIT_AUTOMAKE([foreign]), and if I remove the offending token of [foreign] many other errors come up. So the token in some way seems necessary.
The furthest I have been able to get is leaving the contents of the parentheses empty with a single whitespace character, so it would read: AM_INIT_AUTOMAKE( ). This satisfies the errors but moves the syntax error down a line to: ac_ext=c.
Here is the offending section of code.
AM_INIT_AUTOMAKE([foreign])
ac_ext=c
This is only two lines in a 2000+ line file.
The shell environment is #! /bin/sh
I've tried changing the environment to bash for the sake of being thorough, but it doesn't make a difference.
What am I doing wrong?
The d0_blind_id package (https://gitlab.com/xonotic/d0_blind_id) contains a script called autogen.sh. Run this script (which calls autoreconf -i) to create configure. Run configure and then make.
The configure script should not contain AM_INIT_AUTOMAKE that is part of configure.ac which is used by autotools to generate the configure script.
When I follow these steps I do not get any errors when running the configure script and it does not contain AM_INIT_AUTOMAKE.
I do not know reason you are getting an error as I can not duplicate the issue.
Related
I am trying to run a file using the make command. But when I do this, I get the message:
make: ifort: Command not found
I know that I must set the ifort environment using the following command:
/opt/intel/parallel_studio_xe_2020.1.102/compilers_and_libraries_2020/linux/bin/compilervars.sh intel64
But when I do this, I get the message:
ERROR: libtbb.so.2 library does not exist in SUBSTITUTE_INSTALL_DIR_HERE/lib/intel64/gcc4.8.
Does anyone know what should I do? It looks to me that I must somehow modify the usual variable LD_LIBRARY_PATH to inform where gcc4.8 is.
I can manually find it at:/opt/intel/tbb/lib/intel64/gcc4.8
Where should I put this information?
I am currently using Parallel Studio XE 2020.
Open
/opt/intel/parallel_studio_xe_2020.1.102/compilers_and_libraries_2020/linux/bin/compilervars.sh
with your favorite editor, and look for the line with tbb/bin/tbbvars.sh.
Find the full path for that script. It should be something like
/opt/intel/parallel_studio_xe_2020.1.102/compilers_and_libraries_2020/linux/tbb/bin/tbbvars.sh.
Open that, and look for the line
TBBROOT=SUBSTITUTE_INSTALL_DIR_HERE
and replace with
TBBROOT="/opt/intel/tbb"
I am trying to build Parsec_3.0 dedup workload on skylake server with gcc (Debian 6.3.0-18+deb9u1) 6.3.0. I managed to build streamcluster and canneal successfully without issues, however with dedup I get the error, when using same command: parsecmgmt -a build -p dedup
ERROR:
installing man1/smime.1
smime.pod around line 272: Expected text after =item, not a number
same with lines: 276, 280, 285, 289
POD document had syntax errors at /usr/bin/pod2man line 70.
make: *** [install_docs] Error 255
Makefile:680: recipe for target 'install_docs' failed
[PARSEC] Error: env PATH=/usr/bin:/home/akhorguani/parsec/parsec-3.0/bin:/usr/lo
cal/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/sbin:/opt/dell/srvadmin/b
in:/usr/local/cuda/bin:/grid5000/code/bin:/home/akhorguani/parsec/parsec-3.0/bin
/usr/bin/make install failed.
In /usr/bin/pod2man line 70 is " print " $files[1]\n" if $verbose; ". But it's predefined file from the host machine so I don't think it would contain errors, most likely I might need to change something in parsec files.
So maybe anyone had faced the same problem and can help to fix it?
As jww mentioned, the error is due to some syntax errors on POD files from the SSL library that parsec uses. I had the same error and managed to build by replacing all instances of =item followed by a number with =item C<Number> in the POD files.
The files you need to modify are on the following folders:
$ folder-where-you-installed-parsec/pkgs/libs/ssl/src/doc/apps
$ folder-where-you-installed-parsec/pkgs/libs/ssl/src/doc/ssl
You can see the changes you need to do in this github gist.
I did the changes by hand but you can probably make a script that reads the files and fixes it for you.
I believe that the issue is platform specific because my colleague built it without any problems with Manjaro linux, while I'm using Ubuntu 18.04.
Eduardo's answer worked for me!
It seems the gist is out of date as ome of pod files have changed in the newer PARSEC version.
sed -i.bak 's/item \([0-9]\+\)/item C<\1>/g' *
The script above carries out needed transformation. Run it from apps and ssl folders
I have a script file that I was given to run in windows using Cygwin. When I try to use this file I get the following error
-bash: /sigdet/filename: cannot execute binary file: Exec format error.
sigdet is the folder within the Cygwin directory that I have the script. Rawdata is the name of the directory with the raw data files that the script is supposed to analyze.
To try and solve this, I have changed the file permissions, I have checked to make sure that it is on a 64 bit machine and the script appears to have compiled on a 64-bit machine. After these steps, I don't know what else the problem could be. Here are the commands I've entered:
I first changed the directory like so:
$ cd /sigdet/
Then I ran the script that is suppsed to work:
$ /sigdet/filename -i rawdata
Does the script file need to have an extension in windows? I've tried changing it to a .sh extension with no luck. I'm told that it just works on other windows machines just how it is.
Thanks to anyone that can help with this.
Your file is not an executable. It most probably contains ELF executable which is designed for Linux operating system, or it's corrupt.
If your file was a shell script, or in fact anything that contained plain text, you'd get different errors (such as, "expected command name" or "unknown command: XYZ" etc.)
Scripts are not supposed to have file extensions, like any executables. On the other hand, they should have shebangs: small text located in the first line that tells the system the path to the interpreter. For example, a Python executable script might be named whatever and have #!/usr/bin/python3 or similar in the first line. When you run it through ./whatever in the shell, it'll look for python3 in /usr/bin and run your file like this: /usr/bin/python3 ./whatever. (In fact, thanks to this you can also specify additional parameters that get passed to the interpreter.)
There is also a chance that your script is valid, but it contains a shebang pointing to bad interpreter. If that is the case, then most likely the path is correct, otherwise you'd get /whatever/interpreter: bad interpreter: no such file or directory error or similar. But then, all the other points apply to the interpreter (which is just another executable...)
If the script and/or interpreter was meant to be executed on Windows or Cygwin at least, it should either contain aforementioned shebang (#!/path in the first name) or it should be Windows executable (in which case the file data should begin with MZ letters, you can inspect it in notepad.) If it isn't, it means the files you were given can't run on Cygwin.
Had this same problem. Added the following at the top of makefile:
export ARCH = CYGNUS
What happened during the make process is that Linux and Windows versions of the executables were created. You just have to use ./.exe versions.
In my case, I got the error when I used a wrong command to compile my C program. When I used the right command:
gcc myprog.c -o myprog.exe
the error was resolved.
I have a check for a header file in configure.ac in the source root
AC_CHECK_HEADER(log4c.h,
[],
[AC_MSG_ERROR([Couldn't find or include log4c.h])])
and I'd like to give different feedback on different platform to reflect different most straight forward ways of providing the header:
on Debian it should error with the message Couldn't find or include log4c.h. Install log4c using 'sudo apt-get install liblog4c-dev'
on OpenSUSE it should error with ... Install log4c using 'sudo yum install log4c-devel' (didn't research the package name, but you catch my drift)
on other systems (where I'm too lazy to research the package name) it should error with ... Install log4c by fetching ftp://.../log4c.tar.gz and installing with './configure && make && make install' in the source root
I
checked the AM_CONDITIONAL macro, but I don't get how to use it in configure.ac rather than in Makefile.am (as described in autoconf/automake: conditional compilation based on presence of library?)
found the tip to run esyscmd in stackoverflow.com/questions/4627900/m4-executing-a-shell-command, but adding esyscmd (/bin/echo abc) to configure.ac doesn't print anything when I run autoreconf --install --verbose --force.
Both answers describing the usage of conditional macros without the shell commands for the mentioned OS and links to predefined macros (like AC_CHECK_HEADER_DEBIAN, AC_CHECK_HEADER_SUSE, etc.) are appreciated.
The following configure.ac doesn't work:
AC_INIT([cndrvcups-common], [2.90], [krichter722#aol.de])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign -Wall subdir-objects])
AC_PROG_CC
AM_PROG_AR
AM_PROG_CC_C_O
AC_MSG_NOTICE([Hello, world.])
AC_INCLUDES_DEFAULT
AC_CHECK_HEADER(check.h,
[],
[
AS_IF (test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
LT_INIT # needs to be after AM_PROGS_AR
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
because ./configure fails with
checking check.h usability... no
checking check.h presence... no
checking for check.h... no
./configure: line 4433: syntax error near unexpected token `;'
./configure: line 4433: ` if ; then :'
There's also ./configure: line 4427: #include: command not found which happens no matter whether AC_CHECK_HEADER is specified.
Your configure.ac is almost ok. The only problem is space between AS_IF and the parenthesis. No whitespace is allowed between a macro name and the opening parenthesis in m4 scripts. This is correct syntax:
AC_CHECK_HEADER(check.h,
[],
[
AS_IF(test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
If you are looking for a way to detect different distros look for example at configure.ac of cgmanager.
Update
I noticed one more problem in your configure.ac.
AC_INCLUDES_DEFAULT macro expands to a set of default includes and can't be used here. It is not needed also. It will be used by default in your AC_CHECK_HEADER macro, as you omit last parameter.
This is the cause of line 4427: #include: command not found error you mention.
Update to your comment
First of all, running a system command itself, like lsb_release is not portable. You should first check, for example with AC_CHECK_PROG, for its presence.
Regarding the syntax I would first get the output of the command using backticks: result=`lsb_release -cs` and later test resulting output: test "x$result" = "xvivid". x is needed to avoid problems with empty value in some shells.
At last, I have doubts whether configure script is a proper place for all this distro specific messages. You may consider placing it in the README file.
Avoid those system specific messages.
Print one message which allows people to figure out what package to install on their respective system, but avoid naming the system specific package names and system specific installation tools.
You will never be able to add messages for all systems, so it is better to go the part of the way which you know and let your users go the rest of the way because they know their systems better than you can.
The proper way would be to write a software package outside but called from your configure which, given a header filename, foo.pc filename, library name, etc. figures out how to install that on the respective system. Then let system specific maintainers fix that package, and call it from configure if it is installed, and issue a generic error message otherwise.
A portable shell script local to your software package might do the same job to some extent. You still have to maintain all the system specific parts for all possible systems, though.
Hmm... now that I am thinking about that, the idea appears not that bad. I might add such a script to some of the projects I maintain and see how it turns out in practical use.
I would still try to keep most of that logic outside configure, though.
I am a newbie to Linux and I am only really using it to use a program for my final year thesis. I have got to grips with the language for the program but am having issues with actually running it in Linux. The program is called "CACTUS" and all documentation can be found here.
I have extracted the application file and I have made the executable as instructed in the install.txt file:
"Installation of CACTUS for Linux or Mac machines.
Unzip the directory and put in desired location. On terminal cd into the
correct directory (you should be able to see the makefiles).
Create the executable by typing:
$make
or
$make -f Makefile.gfortran
on the terminal. The executable will be called cactus and be located in the
directory one level above.You can add the executable's location to your path
so that you can call it by simple typing cactus on the terminal instead of
the complete path.
cd into the Test/RegTest directory
$cd ./Test/RegTest
and run the RegTest by executing runreg.py with the path to the CACTUS
executable as an argument (or just the name of the executable if you added it
to your path).
$./runreg.py ../../../cactus
or
$./runreg.py cactus
The output should say 'No differences' for all three tests. Note: if you have
Python 3 installed used runreg_p3.py instead.
CONGRATULATIONS! You have successfully installed CACTUS.
I have run this and I didn't get the "No Differences" returned on the runreg.py. I continued anyway as I did not know why or how I could fix this. (This may be a root cause of my overally problem here)
As I progressed I have been trying to open an input file "TestVAWT.in" from TestCase2 with the following command:
./TestVAWT.in ../../../cactus
From this I get the error in the title returned. Am I correct in assuming that it has tried to run the TestVAWT.in file on the command line without referring to the Cactus application which I presume would be able to read the '&' prefix of the code along with the rest of the input file. Or is it something else I am missing here.
I would appreciate any help as I have been banging my head against a wall for some time now.
Note: I am using Ubuntu 14.04 LTS.
Best Regards
Richard
Don't know the application, but looks kind of strange to me.
Please try adding the Input-File as a parameter:
cactus TestVAWT.in