All,
My host supports Perl CGI scripts, how do I use a compiled CGI script on the host?
I tried setting execute permissions via chmod, but when I try and run it via the browser, I get a server error.
Thanks in advance for all help.
It's possible with a few restrictions:
You're compiling statically or don't have any external dependencies
You're using a glibc that's no newer than theirs
If you're compiling under gcc, you might also need to provide libgcc_s.so which might mean you need a LD_LIBRARY_PATH in which case you'd probably run your binary through a shell script.
You can check the dependencies on your binary with ldd. My recommendation is to compile statically with no dependencies on a system with a glibc at least as old as theirs.
NOTE: (1) above isn't strictly a requirement if you can set LD_LIBRARY_PATH and can run everything through a wrapper script, but things get much more complicated if you need such functionality.
perhaps i'm missing something, but the fact that your host supports "perl cgi" doesn't mean that they support "compiled cgi" (which i would presume is a C CGI program).
Some details about what the server error was would be helpful.
Related
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.
Well the idea goes as followed,
I have a bash file for linux, there I obviously run it by making ./my_run.
The problem is I'm in windows so I downloaded and installed cygwin.
I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well.
When I try to run it with the cmd it displays:
'.' is not recognized as an internal or external command,
operable program or batch file.
As if the cygwin variables were not correctly installed (as I said I tried ls and works).
Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.
So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?
Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.
This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.
In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.
If you open up Cygwin and run the command there you should be fine.
(Note: names of the binary and binary and library below are obfuscated to protect the innocent. ;-) The app is proprietary under NDA but the behavior may not depend on it.)
I have a Linux binary which prints the following error when run:
binary: error while loading shared libraries: libshared.so: cannot open shared object file: No such file or directory
Which is confusing on its own since libshared.so is in the LD_LIBRARY_PATH. However,
The library is found correctly when running ldd binary (i.e., the ldd output points to the file location)
The library is found correctly when running strace binary, so that the program manages to print its usage information!
I have never seen an application which behaves differently when run on its own vs in strace, but I figure maybe someone else has seen this happen before? Any ideas how to resolve this?
I don't have the source so I can't rebuild. Running the app in production under strace is probably a non-starter. The OS is RHEL 6.2.
(Old question, but hopefully this will help somebody else)
Under new Linux installations, LD_LIBRARY_PATH is not used by the standard system runtime linker for programs with SUID set. It appears that strace, gdb and friends work differently, and do use LD_LIBRARY_PATH.
For suid programs, all libraries must be found in the system library cache. Check (as root) whether your "missing" library is present using
ldconfig -p | grep <my_library_name>
and, if anything's missing, add it to a new file in /etc/ld.so.conf or ld.so.conf.d/ as appropriate, and then rebuild using
ldconfig -v
Or remove the SUID bit if it's not required, of course.
This really helped me a lot!
I was having a similar problem where libraries were not being picked up properly from the LD_LIBRARY_PATH, even when the ldd command showed all libraries were satisfied. However, when troubleshooting using strace, it was working. In my case, however, the problem was that SGID (set group ID sticky bit being on). When the files were installed, the sysadmin did a recursive chmod that set it on all files (including the executables). Once the SGID was removed on the executables, the libraries were now found without strace and everything worked as it should using the LD_LIBRARY_PATH.
I am trying to install octave on my machine (Scientific Linux 6.4 based on red hat) without having root access. After running the following:
./configure CPPFLAGS="-I/some_stuff/user_name/bin/pcre-8.32/include" LDFLAGS="-L/some_stuff/user_name/bin/pcre-8.32/lib"
(I had to install pcre apriori; before I got errors re: pcre), I get a message along the lines:
configure: error: You are required to have BLAS and LAPACK libraries
Now LAPACK has just been made in $HOME/bin/lapack-3.4.2 yet the same error is still there. Also $HOME/bin is part of the path.
Any way to tell the configure tool for octave about this? (the obvious thing of adding another CPPFLAG/LDFLAG does not work). I'm assuming I'll encounter more such issues along the way, so any generic help/hint is greatly appreciated.
My level of linux is rudimentary to say the least, but I'm willing to work through it.
Thanks,
Dan
Does this site shed any light on the problem? It describes the configuration options.
http://www.gnu.org/software/octave/doc/interpreter/Installation.html
First, you should rather ./configure all your software with some common prefix, such as --prefix=$HOME/soft/
Unless you know well what you are doing, I recommend against having different prefix for each installed software. You could add $HOME/soft/bin to your $PATH
And you should configure and build all the dependencies before configuring octave (and that includes BLAS, LAPACK and their dependencies).
Then, you want to pass specific configuration options, perhaps like --with-blas=$HOME/soft
I think you should pass the prefix used when configuring BLAS; you may want to run ./configure --help first.
Read carefully each package's installation instructions. For Octave, they are here. Each package has their own.
Some software may require you to configure and build outside of their source tree!
I want to know how to cross compile nginx-1.0.11.
I have already tried : --with-cc option
but it is giving me an error : checking for C compiler ... found but is not working
./configure: error: C compiler arm-linux-gcc is not found
--with-cc-opt is also not working.
I tried to change compiler manually too(by changing a Makefile).
I have already install arm-linux-gcc and its working fine with openssl(It successfully cross compiled openssl. so problem is not with arm-linux compiler).
Any help will be highly appreciated ..
Thanks in advance. :)
There is no easy answer. nginx has it's own non-autoconf configuration system which currently doesn't support cross compilation.
Either hack or avoid the configuration system, or wait until nginx adds support for cross compilation.
See http://forum.nginx.org/read.php?29,220607 where the issue has been recently discussed.
I ran ./configure for my ia32 Linux host, and built it (to make sure it worked), then
1) deleted all object files,
2) edited objs/Makefile to change the value of CC, add include paths for my compiler and library paths for my linker
3) copied some header files from /usr/include to a local directory
There is a problem in that if /usr/include is in the search path, it is searched before the header files for my compiler. This became a problem when x86 assembler instructions were pulled into the definition of htonl().
An alternative is to hack conf/cc/gcc to add an option and do configurations there, includeing supporting a shell variable of CROSS. I haven't done that yet.
Have you considered settng up QEMU - http://wiki.qemu.org/Main_Page and a lightweight image from linaro - http://www.linaro.org/. I have not tested this approach, but i can tell you that I have successfully compiled and running nginx on my Pandaboard ARM v7a.
I successfully cross-compiled nginx by first creating a config on my desktop machine (./configure --without-pcre --without-http_rewrite_module), then just editing the 'cc' command in /objs/Makefile to point to the correct gcc. The Makefile the configure produces is incredibly simple. Just make sure you have all your environment variables set properly as well (CC, LD, LIBS, etc)
I just build v 1.4.7 this way
./configure --with-ld-opt=-L/path/to/libfolder \
--with-cc-opt=-I/path/to/include --prefix=./nginx
make CC=arm-linux-gnueabi-gcc
make install
--prefix nginx installs everithing in ./nginx and one just need to move created nginx folder on device but has to start server from relative path.
./nginx/sbin/nginx