i want to install cpanm WWW::Curl::Form on my Synology NAS. But that fails. Here is the output cpanm WWW::Curl::Form WWW::Curl::Easy File::Find::Rule String::CRC32 URI::Escape
--> Working on WWW::Curl::Form
Fetching http://www.cpan.org/authors/id/S/SZ/SZBALINT/WWW-Curl-4.17.tar.gz ... OK
Configuring WWW-Curl-4.17 ... OK
Building and testing WWW-Curl-4.17 ... FAIL
! Installing WWW::Curl::Form failed. See /var/services/homes/fox/.cpanm/work/1541095458.25803/build.log
the log file gives me:
make: i686-linux-gnu-ld: Command not found
But i dont know how to fix it on my Synology NAS (DSM 6.2 and appollolake architecture DS918+)
After reviewing your additional comments, I believe I have potential solution. It looks like you are trying to install some Perl modules via the default Perl shell, cpan. As part of the installation process, the make utility is being executed. This utility is heavily used for compiling and building source from C and C++ source code, along with other languages.
The make utility is trying to call some executable i686-linux-gnu-ld which is a linker, see ld. A linker is a utility used in C programming for linking (combining) multiple compiled object files into a single executable binary. make is calling this utility as some sort of build process. Instead of calling i686-linux-gnu-ld it should probably just be calling ld. The only thing I am not sure about is why it is using the full name of the utility instead of ld.
I can think of two solutions. The first would be to update the make file to use the correct name for the linker. I'm not sure how you would do this when it is being installed via cpan since it is downloading a package and executing the make file before you have a chance to modify it. The other option is to create a symbolic link from the incorrect name and path of ld that the make file is using to the correct path /opt/bin/ld. This will result in ld being called when i686-linux-gnu-ld is called. Also, I forgot to mention it earlier but the which command will tell you where an executable / command is located on your shell's path.
The Stack Overflow post, How to symlink a file in Liunx?, gives a good explanation of how to create a symlink. You need to create a symlink to point to the correct name and path of the linker. To do so run the following command:
ln -s /opt/bin/ld /usr/bin/i686-linux-gnu-ld
Depending on the permissions of these directories you may need to run this command under a account with elevated permissions or via sudo. I apologize for this post being rather long and verbose. I just wanted to explain my solution in detail. I hope this helps. Please let me know if this doesn't resolve the problem.
edit: fixed typo in the command.
Related
I have installed gprbuild, xmlada, and gnatcoll. I am now attempting to install gnatcoll_postgres. Which I have downladed from here: https://github.com/AdaCore/gnatcoll-db/
Within the Postgres folder is a Makefile, which I execute like so...
[parallels#localhost postgres]$ ls
gnatcoll_postgres.gpr gnatcoll-sql-postgres-gnade.ads
gnatcoll-sql-postgres.adb gnatcoll-sql-ranges.adb
gnatcoll-sql-postgres.ads gnatcoll-sql-ranges.ads
gnatcoll-sql-postgres-builder.adb Makefile
gnatcoll-sql-postgres-builder.ads postgres_support.c
gnatcoll-sql-postgres-gnade.adb README.md
[parallels#localhost postgres]$ make Makefile
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
[parallels#localhost postgres]$
Would anybody please be able to tell me what this means...
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
Any help would be greatly appreciated.
Please see the xmlada and gnatcoll in my project below, does this look like it's installed correctly? I'm presuming this isn't correct...
Thanks,
Lloyd
It means that your GNAT installation binaries aren’t on your PATH.
The README.txt from the adacore.com site says, in part,
To start using the tools in command-line mode, you will need to add
{install_prefix}/bin
to your PATH environment variable. Alternatively, you can simply launch
{install_prefix}/bin/gps
and GPS will automatically add itself to the PATH - it will also find the
cross compiler, if you have installed everything in the default locations.
Note that GPS will add this at the end of the PATH, meaning that it will find first any other GNAT installations that you have in your PATH.
I strongly suspect that you’ve been doing the latter, so that GPS adds itself (actually, of course, its own location) to the PATH, so that when it launches the compiler it finds the correct one.
When you run make from the terminal, the compiler isn’t on the PATH, so neither are gnatls, gprconfig, gprbuild and the rest of the GNAT tools.
What you need to do is to take the first choice from the README, and add /home/parallel/opt/GNAT/2019/bin to (the front of) your default PATH. How you do that depends on your shell.
You will find xmlada, gnatcoll already installed.
I'm trying to compile geany-plugins-1.28. The debugger plugin (the only one I need) gives the error:
debug.c:53:21: fatal error: vte/vte.h: No such file or directory
#include <vte/vte.h>
Clearly it needs to know where this file is located to compile. I found the vte.h file in the src directory of the main program geany-1.28. When running
sudo ./configure cflags=-I/home/pi/Desktop/geany-1.28/src
I get the same error about the missing header later trying to compile the debugger plugin.
I ran
./configure --help
to get all the flag options. The output is here
How do I get this to configure correctly so that it compiles. I need to compile the debugger version 1.28 myself because apt only installs 1.24 which I think has a bug because it crashes when I run my code with the error:
close failed in file object destructor:
sys.execpthook is missing
lost sys.stderr
CFLAGS is case-sensitive environment variable, so you should set it before running configure, not try to pass it as a command line argument. This variant:
$ export CFLAGS=-I/home/pi/Desktop/geany-1.28/src
$ ./configure
leaves CFLAGS set for current shell until you leave it. While this:
$ CFLAGS=-I/home/pi/Desktop/geany-1.28/src ./configure
sets variable only for current command, i.e. configure.
Some other issues:
You do not need sudo to configure and make. It is also unnecessary for make install if you set PREFIX to a path you have privileges to write to.
Does plugin's build system also builds all it's dependencies? If not, you may face linker errors a bit later.
Update:
I have tried to build debugger plugin and got rid of your error. It seems that vte.h coming with Geany is it's intrinsic, while the plugin requires full-featured file from the library. So I just installed vte and vte-devel from repos. Nevertheless, I got some other unrelated errors coming from Glib. I will not continue my attempts to build all this right now. Hope my effort will be helpful at least a little.
As in this answer stated, vte.h is not the file you are looking for. Install libvte(-dev) package on your system and rerun configure.
Just for the record: vte.h on Geany is a dummy to allow Geany to kind of dynamical enable vte or disable it depending on vte is installed on the system or not.
I have instaled Cygwin after running MinGW for a while now. But when I try to compile the console gives me:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
What does this mean?
I have the same problem and I found the solution.
According to the FAQ of Cygwin
Q: Why is C:\cygwin\usr\bin invisible from windows?
A: Because it does not really exist. In cygwin, /usr/bin is just a link to /bin.
So trying to add "C:\cygwin\usr\bin" to PATH will be in vain.
Add "C:\cygwin64\bin" to PATH instead. Hope this helps :)
You are missing a library, please run cygcheck /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe or ldd /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe to see what is the missing library.
(I'd rather ask a question in the comments first, but I don't have enough reputation yet.)
Your cc1 is unable to load some DLLs it needs to start. Looking at the Cygwin source code, this can be either a library specified in LD_PRELOAD, or -- more probably -- a library the executable depends on. The ? in the error message seems to be the default return value of find_first_notloaded_dll (hookapi.cc), in case the function can't determine what library is missing.
To diagnose the issue, I suggest checking your PATH variable (or even clearing it of any non-Cygwin paths and trying the compilation again) and/or using Dependency Walker to find the missing DLLs (start it from a Cygwin shell, so it can see the same PATH). ldd (included with Cygwin) may also give some clues, but I wouldn't bet on it.
It's possible a clean re-install of Cygwin will be necessary to solve the issue.
Most likely, you are simply missing /usr/bin in the PATH variable.
Adding 'export PATH=/usr/bin:$PATH' to your .bashrc file will solve the issue.
Adding some background info. I had the same problem when building my own program and linking it against graphviz cgraph.dll. Turns out this is related to where windows searches for DLLs (see here: https://msdn.microsoft.com/en-us/library/7d83bc18.aspx) So adding the path of your missing library to PATH should fix the problem.
It is unfortunate that the message doesn't include the name of the library. Luckily cmd.exe DOES give you this name (so it's good for something after all;)
Are you including the path to your lib directory?
Looks like you are not
I'm not very familiar with Cygwin, I mainly use MinGW, but I think the error message speaks for itself
I also came this error on windows machine while executing .exe file generated by scilab2C i.e toolbox for Scilab
For Windows 32 bit Add the environment variable path as follow :
C:\cygwin\usr\i686-pc-cygwin\bin
Hope so this will solve your issue.
Just had this problem trying to compile a package with make and it wanted some cygguile dll file that was just installed along with make.
My solution was I had not only migrated my cygwin64 directory across drives because the sector sizes were mismatched for some reason even though the drivers were both under 2TB and should have been using 512 byte sector sizes.. So I had to install a new system and move files over there, might have had weird permissions on them.
Also had to patch cygwin1.dll end of Jan 2020 because of a recent input problem in ConEmu with Windows 10 1903 build, but just did it again with this working so that doesn't seem to be the issue.
Reinstalling cygwin by deleting that entire directory, taking ownership of it first.., seemed to work now...
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.
recently, i try to compile a gnu wget from source code in cygwin environtment that pop-up error if perl is not found. otherwise, perl is installed both perl and perl5 on /bin/ but the wget is try search perl on /usr/bin. i think i have missed basic ./configure to setup path executable. so my question is basic.
what is it all about options on below:
*
--bindir=DIR
--sbindir=DIR
--libexecdir=DIR
*
Thank you
These options specify directories where a software package being compiled is going to be installed. As far as I remember it doesn't deal with checks performed by configure. Make sure that perl is in $PATH. If nothing helps, try to locate the exact place in the configure script (usually it's robot-generated and not intended for human eyes, but afterall it's a shell script, and anybody can read it) and see what checks exactly are performed to locate perl.
Update: I have checked, the tests corresponding to perl look like this in configure.ac (which essentially is a "source code" for configure):
AC_PATH_PROGS(PERL, [perl5 perl], no)
AC_PATH_PROG(POD2MAN, pod2man, no)
This means that PERL with executable named perl5 or perl (somewhere in $PATH) is checked, and then POD2MAN with executable pod2man. Carefully check the configure output and config.log file and see what tests have failed.
Update2: The third argument of the AC_PATH_PROG and AC_PATH_PROGS is value-if-no-found. Also you may specify the fourth argument, $PATH for this particular check. Make sure that configure gets rebuilt after you changed configure.ac (usually it happens automatically, but may be performed by autoconf explicitly)
what is it all about options on below:
*
--bindir=DIR
--sbindir=DIR
--libexecdir=DIR
The first (bindir), is where binaries will be installed. For wget, that's (on my system) /usr/bin.
The second (sbindir), is where static binaries will be installed. You might set that to /usr/sbin.
The third (libexecdir), is where your runtime libraries are to be installed. That's usually /usr/lib.
In fact, usually you let configure set all three by using --prefix.
./configure --prefix=/usr/local