I am compiling a C code using the intel compiler. I integrated icc with visual studio 2010. I want to generate an optimized executable which will run on a windows machine. It is actually a virtual machine in the cloud. I don't have a chance to install any redistributable library to the target machine. I want to statically link all the required libraries. How can I do this?
I suppose you meant icl since you're mentioning VS2010/Windows (icc would be Linux/Mac version): just selecting 'Multi-threaded (/MT)' under Project settings->Configuration properties->C/C++->Code Generation should work. It'll cause both MSVC and Intel runtime to be statically linked into app.
But then it also depends which other libraries are you using, it might not work for all. In that case you can check the dependencies with depends.exe (http://www.dependencywalker.com/) and copy them side-by-side with your .exe to target machine.
Try adding -i-static -static-libcxa to the final linkage.
This should force static linking for intel libraries only.
(You can also try -static as littleadv suggested in the comment, but this will produce a huge static executable with no shared libraries at all)
One more note: A simple workaround would be to copy the executable with the required shared libraries (those that do not exist at the host) to the same directory. Then set LD_LIBRARY_PATH=. before running your dynamically linked executable. This will force searching for libraries in the current directory as well as system directories.
EDIT: I just noticed you said "windows machine". The above is relevant to UNIX machines so probably not useful to you. I'll leave it here in case someone needs the information.
Related
I'm either failing hard at Google today, or this is something which is non-trivial.
I have an application that I am working on for a Windows system, cross-compiling from Linux because (a) I need C99 and Microsoft's free tools for the target system does not support it and (b) I've been using UNIX for nearly 30 years anyway, and that's my "home". Changing to an MSVC stack with "native" building is not an option for me, nor is running the GNU build system on Windows (it takes forever).
The problem is that I need to have a single tool built for the system being compiled on and not the target; I need to then run that executable which will generate several .c source files and .h headers which then enable the project to compile. I am using the so-called "GNU Build System" (that is, the autotools, including autoconf/automake/libtool).
Any recipe I write will, regardless if I configure for i686-w64-mingw32 or x86_64-w64-mingw32, compile all DLLs and EXEs for the Win32/Win64 platform.
There is a way that I can force the issue by hand-crafting standard Makefile receipes, but I was trying to find an "autotools native" way of compiling and running build-time executables that are not e.g., unit tests, but source code generators.
Any ideas, short of hand-crafting Makefile recipes?
ETA: Additionally, the project is cross-platform: it does make sense to compile this one natively for Linux as well, so any solution needs to work just as well when not cross-compiling.
I've written a Linux program in C, and I'm trying to get it to run on a server system. It looks like everything should work, but when I try it, I get this:
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by <program>)
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./libdbi.so.1)
(Where <program> is my program's name.)
So far as I can tell, my program only requires that version of GLIBC because libdbi does. I've tried compiling libdbi from source, and it still attempts to link to that version of GLIBC.
I don't own the server system (it's a shared system I run a website on, and have SSH access to), so I can't make any changes to it -- that's why the library file is in the same directory, and I've set LD_LIBRARY_PATH=.. Unfortunately I also don't have access to a compiler on it -- when I try to run GCC, I'm told "permission denied". It's run by a big corporation, and I'm only one customer; the chances of them making any changes at my request are essentially zero.
Is there any way to compile the program on my system so that it will work on the server?
Before I asked, I found these similar questions:
Compile C program in Linux with different glibc library: the link in the answer goes to a 404 page, and from what I've been able to determine, apgcc isn't available on Debian distributions.
Relink a shared library to a different version of libc: seems to say that this problem doesn't exist, because "glibc tend to be backwards compatible" (except they apparently aren't in this case).
How to compile Linux C program to run on another Linux machine?: suggests a chroot or virtual machine, which I've done before elsewhere, but how can I tell it to use a libc without that old GLIBC version?
is binary executable file portable: suggests static-linking, but libdbi dynamically-links to its driver files, so that apparently can't be done -- I get several errors referring to missing functions like ldopen.
There are others, but they seem to be variations on those.
I'd be willing to use a non-free solution (like one that I saw in another answer I can't find now) if I turn this into a commercial product, but for a single use it seems like massive overkill, not to mention the expense.
Is there any way to simply tell libdbi to link to a later GLIBC version, maybe? If not, is there any solution I've overlooked?
Big corporation or not, the least they owe you if you are paying for service in any way or being paid for development to meet a requirement is a careful description of the runtime environment so you can duplicate it on a development machine.
Then you must set out to systematically duplicate this environment. Since you're using libdbi you should be thorough. Database connections can exercise big chunks of the system API, so you want to have exactly the same version of Linux, gcc (even if you can't run it, you need to know the version other parts of the system were compiled with), and other tools and libraries. If you don't, you won't be able to have much confidence that your development machine tests translate to good behavior on the target.
A virtual machine is a good way to create a specialized development environment without messing up your existing one.
You must compile it on a machine that has the same version of glibc as the target machine, or an older version. shared library compatibility works in that direction only.
Find out what version of Linux the server uses, get a copy of it and install it in a VM
Virtualbox is good for this
You can use this environment for testing code as well as this particular compilation problem
You have the following options:
Compile your code on the server machine (which likely has gcc installed)
Compile your program with statically linked libraries (option -static for gcc)
I'm trying to make an audio file I create slow down using SoX, and although I can easily compile the source files on the linux machine I use regularly, I need to transfer the binary to another linux machine with limited permissions and memory. I tried to copy the binary from the usr/local/bin folder on my machine to the other one and it could not find function references.
Is there a standard way to compile binaries with no dependencies, and if not, how do I set up the SoX binary so that it sees the correct dependencies when I only have write privileges in a temp folder?
You can compile, adding the -static flag to the compilation options in the Makefile. But be aware of any differences in glibc versions between your two (or more) Linux workstations. You want to make sure that you compile on (or target for) the workstation with the older (or oldest) kernel, or your binary may not work due to dependencies on a newer kernel, which cannot be met by an older installation of Linux. So: basically, compile on your oldest machine for better results.
The most important thing you need to generate executables without dependencies is the static version of all libraries this executable will use. Usually, libraries are shares as well, meaning if they need to call another library's functions, they use shared linking. To not get 2nd-grade dependencies you need to compile all required libraries statically.
I have a C code created in Plato3. I want to create an exe file so I can share it with others.
Can someone please tell me how is this possible ?
I have tried sending the exe file that is created when normally compiled, but it crashes every time in runs on computers other than mine ...
Please help,
Thanks :)
[EDIT]
Program running on windows xp or vista .. same error :
Compiler used : SilverFrost (Fortran/C/C++) Development Studio (Plato3)
This application has failed to start
because salflibc.dll was not found,
reinstalling the application may fix
this problem
salflibc.dll is a library installed by the compiler on your development machine.
salf = Salford C Compiler, the obscure compiler included in Silverfrost
libc = C-language runtime support library, necessary for the basic functionality of any program
.dll = dynamically-linked library, i.e. a separate file from your .exe file
You might look for a compiler option that looks like "statically link runtime library;" this might eliminate the DLL dependency. However, if the compiler were capable of doing that, one would expect it to be the default, if not the only way.
However, I recall from the olden days of Classic Mac OS that sometimes DLL runtime libraries were used, the benefit being upgradability. Sometimes is a key word, though. (I suppose when the compiler vendor is the OS vendor, as with MSVC or Apple GCC, it is the norm, though.)
Another trick from that environment was to put the DLL in question in the application's directory and distribute it with the app. Typically runtime DLLs are licensed for free redistribution.
At the very least you have to make sure that the executable is running on the same architecture/operating system that it was compiled on.
Additionally, you need to make sure that any third party, or system libraries that are needed are available on the other systems too.
update
Based on the new information and error message you provide, it looks like you need to re-distribute the salflibc.dll
I would agree with other commenter's and suggest a different platform for development that is more mainstream, or supported.
I been looking into Cygwin/Mingw/lcc and I liked to be able to compile perl native C extensions on my windows(preferably under cygwin) and then run them on Solaris and HP unix without any further fuss, is this possible?
This all stems from my original perl cross-platform question here.
(This is a very old question, but missing some useful info --
I've personally done this for Solaris (SPARC & x86), AIX, HP-UX and Linux (x86, x64).)
Getting C++ cross-compiled is much harder than straight C.
HP-UX 32-bit PA-RISC is not supported because it uses SOM format instead of ELF and binutils doesn't (and likely won't ever) support SOM. In other words, you can only cross-compile 64-bit PA-RISC. (Requires PA-RISC 2.0 chip.)
I would go with mingw instead of cygwin, if you can. Cygwin introduces a lot of file permission headaches and cygwin1.dll dependencies that can be troublesome. If possible, however, build on linux. Everything will be much faster because all the tools and scripts you're running are designed for an environment where exec and stat are fast operations. Windows + NTFS is not that environment.
Start with the crosstools script, but be prepared to spend a lot of time on this.
Try with the very latest gcc/binutuils first, but if you can't overcome problems try dropping back to older packages. E.g. for Power3 (AIX) gcc 4.x series cross compiler generates bad code, 3.x is fine.
When copying native libs and headers make sure you are copying from the oldest machine you're likely to run on. Copying a new libc means your code won't run on any machine with an older libc.
When copying native libs and headers you probably want 'tar -h' to turn symlinks into actual files, also watch that on Solaris some requisite crt object files are buried in a cc directory, not under /usr/lib
Cross-compiler are very hard to setup and get working correctly.
Consider that (the people at) NetBSD have to put in a huge amount of work to get cross-compiling to work, and they're running the same OS, just different architectures.
You'd have to, at least, copy all the headers from the other OSs to Windows, and get a cross-compiler, linker etc for the target OS/architecture.
Also that may well not be possible - perl and shared libraries may be compiled with a native/non-gcc compiler which won't be available on Windows at all.
I agree with Douglas, that getting a cross compiler up and working is very hard to do. This is generally, your choice of last resort. If you are boot strapping, or making a binary for an embedded device, then often cross-compiling is your only option. You should be comfortable compiling your own gcc under Cygwin before considering cross compiling. To cross compile, you need to build a gcc to run under windows, but which will create binaries for your execution platform. Sample instructions for doing this can be found here.
Perhaps you are wanting to cross compile because you don't have root and/or can't compile on your target platform. For example, I had a hosting provider which ran Redhat Linux. I could run Perl CGI scripts, and associated modules, but I could not compile on the target machine, and an libraries I built had to exist in my own directory.
To solve this, I could have attempted to cross compile for my target platform, but instead, I decided to setup a similar host inside a VM on Windows. From within Cygwin, you can create a script which ssh's into your VM, copies your source, and does a full configure/build. The last step was to deploy the binary artifact onto my hosted system.
I've successfully had both Solaris 10 and Open Solaris running within a VM on Windows. Unfortunately, you might have a harder time running HPUX under a VM.
Why don't you have a read up on "Grand Unified Builder" (http://lilypond.org/gub/ and http://valentin.villenave.info/The-LilyPond-Report-11 (section #4))
I don't know how it works, but GUB allows the Lilypond developers to compile for about 11 platforms on a linux box.
Compile on Windows then use Wine to run them on any *nix. It works well most of the time.
No, this isn't possible at the binary level. There are so many differences at binary level between the various OSes and CPUs.
But what you can do is make the your C extensions source compatible so that it can compile to different platforms. C was designed as a "portable assembly language". As long as you stick with routines that are cross-platform, then they will usually work the same. You'll still need to test because there could be bugs that exists on particular platform.
This can't be done ... but is it that much of a hassle to recompile the code under Solaris or HP?