I have compiled an Ada program on Ubuntu using GNAT.
Afterwards, I tried a few test runs with that program and it worked properly.
But when I uploaded this to my Apache (UNIX) webserver and tried to run the program, there was no output. Why is this so?
Could it be that programs which have been compiled on Ubuntu don't work on a UNIX server?
(Sorry for the stupid question!)
Linux version of the system I use for compiling (uname -a):
Linux ubuntu 3.0.0-12-generic #20-Ubuntu x86-64 GNU/Linux
Linux version of the system I want to run the program on later (uname -a):
Linux 2.6.37-he-xeon-64gb+1 i686 GNU/Linux
For compiling on the Ubuntu machine, I use:
gnatmake -O3 myprogram -bargs -static
When you build a GNAT program (gnatmake my_program), by default it links against dynamic libraries (libgnat.so, libgnarl.so). These libraries are part of the GNAT system and are very unlikely to be available on your web server.
If you say ldd my_program it will show you the shared libraries used.
You can force the build to use the static GNAT libraries by saying
gnatmake my_program -bargs -static
(the -bargs -static must come after regular flags like -O2).
Edit: more info on -bargs and friends.
You must make sure that the server has the libraries your app links against or link them statically like already suggested by others. Some other comments point out that you need to "cross compile" or that the server won't run 64 bit binaries. This is easily solved unless the app you're building is very complex.
gnatmake --GCC='gcc -m32'
Will make a binary that will run on a 32bit system. However the chief problem is that the servers (g)libc is very likely to be older than what's on your ubunu box. Programs compiled against newer glibc will not necessarily run on systems with an older glibc installed.
for more info and plenty more links, look here:
Linking against an old version of libc to provide greater application coverage
How can I link to a specific glibc version?
edit:
Besides, apache may not be configured to accept invocation of external binaries. Have you "tried to run the program" with something you know exists on the server? Try to run something trivial like /bin/ls to make sure your method of running the program works. Look at the logs if it doesn't work. Programs need to be executable, by the way: chmod 755 /path/to/webeserver/uploads/ada-app
Why don't you just compile it on your Webserver instead of your local machine ?
Aswell cat /etc/issue or cat /etc/release could give us some information about the distribution you're using.
Related
I'm confused about the environment. Using MSYS2 under Windows, I want to compile, say, the boost library:
http://www.boost.org/users/history/version_1_64_0.html
What file I have to download? The one for Windows or the one for unix?
MSYS2 is a not a Unix environment. It is a hybrid environment made up of these main components:
POSIX-emulation layer called msys-2.0.dll, which is a fork of cygwin.
Tools like GNU Make, Bash, and ls that depend on the msys-2.0.dll runtime.
pacman, another msys-2.0.dll program, that lets you install precompiled packages from the MSYS2 developers.
Native Windows software, which lives under the /mingw32 (for 32-bit) and /mingw64 (for 64-bit) directories.
Anyway, it seems like you are just getting started with MSYS2 and don't know much about it. If your goal is to write native Windows software that could some day be used outside of MSYS2, you should install the native Windows version of Boost provided by the MSYS2 developers. So run one of the commands below:
pacman -S mingw-w64-i686-boost
or
pacman -S mingw-w64-x86_64-boost
Then make sure you are using the right flavor of MSYS2 shell, and make sure you install the corresponding GCC toolchain. For 32-bit development, you must launch MSYS2 with the "MinGW-w64 32-bit Shell" shortcut and use pacman to install mingw-w64-i686-toolchain (pacman -S mingw-w64-i686-toolchain).
If you try to download binaries from boost's website, you will likely run into all sorts of compatibility issues. It's better to use software built using an MSYS2 GCC toolchain, especially if MSYS2 already has a package for that software.
I have developed some codes in Linux which use boost::serialization library. Now I want to copy my files into Cygwin and compile them to produce executable for Windows. I know that I should use Mingw-64 g++ compiler. But how about boost library? Should I download the Windows version or the Linux version of this library?
In Cygwin, you install Boost libraries as per Unix/Linux. From the documentation
Getting Started on Windows
A note to Cygwin and MinGW users
If you plan to use your tools from the Windows command prompt, you're in the right place.
If you plan to build from the Cygwin bash shell, you're actually running on a POSIX
platform and should follow the instructions for getting started on Unix variants.
Other command shells, such as MinGW's MSYS, are not supported—they may or may not work.
I am trying to test Debian packages which are built on an x86 Linux system, but which will be executed on an ARM architecture. My {pre,post}{inst,rm} scripts are failing with a "exec format error" because the /bin/bash in the chroot'd environment, which is an image of a flash filesystem, are ARM binaries, not x86 binaries.
What I'm looking for, but cannot find, is an option to dpkg which is like --root, but which doesn't use chroot. I'd presumably need to know the name of some environmental variable (?) which contains the name of the parameter to --root.
It's probably easier to make the /bin/bash (and everything else) in the chroot executable.
Install qemu-user-static on the host. That will give you QEMU user space emulators for all architectures in static versions — so no complications with dynamic libraries in the chroot. It also configures binfmt support to execute ARM binaries with /usr/bin/qemu-arm-static.
Copy /usr/bin/qemu-arm-static into the /usr/bin of the chroot. Now you should be able to chroot and run programs normally. That way your Debian packages can be tested chrooted into their (emulated) native environment.
Alternatively to the good suggestion to use qemu, starting with dpkg 1.18.5 you could use --instdir in conjunction with --force-script-chrootless. Depending on the maintainer scripts you might need to adapt them to make use of the DPKG_ROOT environment variable. There's more information in the dpkg man page.
I am trying to make programs for an old computer running Windows 98 second edition, but they won't run.
The programs are written in c++, and they are compiled with MinGW (g++ version 4.8.1) installed on a Windows Vista computer. For testing I tried this simple Hello World program:
#include <iostream>
using namespace std;
int main(){
cout <<"hello world";
return 0;
}
For compiling I used this command:
g++ hello.cpp -o hello.exe
When trying to run this program on the Windows 98 computer I get the following message:
A required .DLL file, LIBGCC_S_DW2-1.DLL, was not found.
So to make the executable as independent of dll-files as possible, I tried compiling the program with the command:
g++ hello.cpp -static -o hello.exe
But on trying the program on the Windows 98 computer, I now get the message:
The hello.exe file is linked to missing export MSVCRT.DLL:_fstat64
To analyze the problem, I tried a few things. And I noticed that compiling the same code with the same command using g++ version 2.95.2 instead, the program was able to run on the Windows 98 machine. However, I would prefer not to use this old version of g++ as it contains a few problematic bugs.
I also noticed that a similar program made in regular c (compiled with gcc version 4.8.1) also worked fine on the old computer, but I would prefer not to use regular c as this would require rewriting a lot of c++ code.
So the question is: how can I make c++ programs compiled with g++ 4.8.1 (or later) run on a Windows 98 machine?
Late but better than never
found out later versions of MinGW doesn't run on windows 98 giving the error "A required .DLL file, LIBGCC_S_DW2-1.DLL, was not found."
the version of MinGW i tried and gave the error was this one (6.3.0-1)
(i think you are referring to the dev version there, probably the bin version you had was more modern)
oddly, i recalled that time ago i compilled a build using Code::Blocks using MinGW that ran in windows 98, so i downloaded Code::Blocks version 17.12, and compilled the very same exe using the MinGW provided there directly, and worked just fine
and noticed it was a fairly older version ((tdm-1) 5.1.0)
idk which was the latest version MinGW compilations worked on windows 98, i'll write a post about it in their forum soon
for the record, i'll show the pics of the test i did
on MinGW 6.3.0-1:
on MinGW (tdm-1) 5.1.0:
so, to answer the question; yes, you can make programs for windows 98 using MinGW's g++ greater than version 4.8.1 (up to a certain version, i'll ask in the forum for more information)
EDIT: no need to, found this:
"The default mode is C++98 for GCC versions prior to 6.1, and C++14 for GCC 6.1 and above. You can use command-line flag -std to explicitly specify the C++ standard. For example,
-std=c++98, or -std=gnu++98 (C++98 with GNU extensions)
-std=c++11, or -std=gnu++11 (C++11 with GNU extensions)
-std=c++14, or -std=gnu++14 (C++14 with GNU extensions), default mode for GCC 6.1 and above.
-std=c++17, or -std=gnu++17 (C++17 with GNU extensions), experimental.
-std=c++2a, or -std=gnu++2a (C++2a with GNU extensions), experimental."
i added the -std=c++98 -std=gnu++98 flags to the 6.3.0-1 compiler and it worked fine on Windows 98 SE
You can usually find msvcrt.dll by installing IE4
http://gnuwin32.sourceforge.net/packages/gcc.htm
I'm trying to port some software over to Solaris 10 Sparc, using GCC 3.4.6, and the software's build system uses cmake. When I run the command cmake CMakeLists.txt, I get a lot of output like this:
ADD_LIBRARY for library <library_name> is used with the SHARED
option, but the target platform supports only STATIC libraries.
Building it STATIC instead. This may lead to problems.
Obviously Solaris 10 Sparc supports shared libraries, and I have built this software on x86 Solaris 10 before.
Anyone run into this or can provide direction? I'm about to dive into the cmake source to figure out if it has issues with Sparc Solaris.
Thanks.
After fighting with this a couple hours, and making little headway, I decided to install cmake-2.8.6 from OpenCSW using pkgutil, and this issue cleared up.
Also asked this question in #cmake#irc.freenode.net before I fixed it, looks to be an issue with cmake 2.6.4 on Sparc Solaris 10.