I have a Fortran ".exe" file generated in Windows. I want to link it with other Fortran routines while compiling on Linux platform.
For example, I have "a.exe" file generated on Windows. I wrote "b.f90" and "c.f90" on linux machine. I want to compile "b.f90" and "c.f90" and link them to "a.exe" to generate the final ".exe" file.
Is it possible?
No, it is not possible.
(Or it would be very very complicated and the .exe would have to be specially prepared for that.)
Not only Linux and Windows executables are incompatible. You do not link an .exe with anything, not on Windows, not on Linux, nowhere (except linking with the .dll or .so dynamic libraries the executable always requires). What you normally do is that you compile your Fortran or other language sources to object files and then you can link the object files to form a library (dynamic or static) or to form an executable.
What you could theoretically do, IF the .exe file already requires some .dll libraries, or is able to load some on request, is to compile your .f90 files to make these .dll libraries (somewhere with Windows or with a Windows compiler under Linux in Wine or with a cross-compiler) and then run everything under Linux using Wine. But I would just recompile everything on Linux from scratch.
Related
I have written a prolog program in GNU-Prolog and successfully compiled it , now I want to create an executable file so that the other person only need to click on that file and run the program. I want to know if there is a way to create an executable file from a GNU-Prolog program?
Under Windows, to compile to an executable you need a C compiler toolchain. Depending, on the version you installed, you need the Microsoft C++ compiler (MSVC) or with gcc (provided by MSYS2/mingw64).
For MSVC, you can install Microsoft Visual Studio 2019 Community (version 19.28.29335). Once installed, there are 2 .bat file provided with the MS compiler
e.g. vcvars32.bat and vcvars64.bat. Launch the appropriate .bat to obtain a terminal with PATH sets for MSVC.
For gcc, you should install MSYS2 + the gcc toolchain. More information is available here WINDOWS information (the file details how to compile gprolog on WINDOWS using either MSYS2/gcc or MSVC).
The gprolog compiler is in the bin sub-directory of the GNU Prolog installation (by default C:\GNU-Prolog\bin). You need to add this directory to your PATH.
Go to the directory containing your Prolog file (cd path_to_your_file) and compile it with gplc your_file.pl.
As mentioned by Paulo, you'll find more information on options you can pass to gplc in the online manual.
I'm trying to compile a shared library with cmake to use it further with the "dlfcn" lib in a C program. I am on Windows with Cygwin, but I don't know how to use "dlfcn" with the shared libraries of windows (.dll and .dll.a) and my teammates are using Linux. So I would like to create not .dll and .dll.a libraires but a .so library. I'm a beginner with cmake, is there a possibility to do it or am I obliged to install a Linux VM ?
So, thanks to #Florian, I finally made it. To the ones who want to know how it works, it's quite simple :
Create a new .cmake file :
# this mandatory command will be the one that will make your cross-compiling work
set(CMAKE_SYSTEM_NAME Linux)
# indicate compilers (optional)
set(CMAKE_C_COMPILER gcc)
set(CMAKE_CXX_COMPILER g++)
When calling your cmake command, add an argument like this :
cmake -DCMAKE_TOOLCHAIN_FILE=./myToolChainFile.cmake ..
I am trying to link glfw on windows.
On Linux it was fairly straight forward:
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps/glfw/build/src/libglfw3.a" platform="posix"
libs"Xi" "pthread" "X11" "Xxf86vm" "Xrandr" "pthread" "GL" "GLU" "Xinerama" "Xcursor" platform="posix"
If I try to link with a .dll on windows, dub tells me that Error: unrecognized file extension dll.
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps\\glfw\\build\\src\\Debug\\glfw3.dll" platform="windows"
If I try to link with a .lib, dub tells me that COFF is not supported.
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps\\glfw\\build\\src\\Debug\\glfw3.lib" platform="windows"
GLFW was built with vs2013. What do I have to do differently?
There's three cases here:
Default 32 bit Windows build. dmd on Windows, by default, builds 32 bits using the old OMF linker format. You cannot link straight to a dll and need a .lib. But since it uses the old format, most .libs provided won't work - you have to make your own.
(lol i want this in the list item but markdown sucks. whatever)
Download this thing to get implib.exe: http://ftp.digitalmars.com/bup.zip
and use that to make a .lib from the .dll: implib /s yourdll.lib yourdll.dll and try to link with the new lib. (Add it to the files list like you are already doing)
If it doesn't work, try the command again, but this time without the /s switch.
It should work by then.
-m32mscoff 32 bit builds. With that flag to dmd, it will output a 32 bit program using the new COFF format instead of the old omf format. For it to work, link.exe in your path MUST be the Microsoft linker, from Visual Studio, instead of the default Digital Mars optlink.exe (which, confusingly, was also called link.exe until recently. That was nice when it was a compatible replacement for the Microsoft one.... twenty years ago...).
Anyway, if you have the Microsoft C++ compiler and linker installed and put that link.exe in your path, dmd -m32mscoff should work using existing .lib files from the dlls.
TIP: If you used the Windows installer for dmd, open the "D2 64 bit command prompt" from the start menu to get the path set up. It will tell you to use -m64, but you can also use -m32mscoff from that environment and it should work. if everything installed properly.
-m64 64 bit builds. Basically the same as the mscoff switch - you need the Visual C++ linker in your path - but does 64 bit instead of 32. Of course, this requires a 64 bit dll and lib to be there too.
In the comments, it sounds like you might also be facing some bugs, I don't know about that, the above is if everything else is working properly.
I'm trying to compile a library (dxflib) for use in windows using cygwin.
I'm loosely following the instructions found here: http://www.ribbonsoft.com/doc/dxflib/2.5/reference/dxflib-reference-manual.pdf
I can get it to compile to make a .a library (ie a unix static library), using 'make' but obviously I'm using cygwin because I want to compile a .lib for use in windows.
When I try to use 'MinGW32-make' (or any other derivative I can think of) cygwin claims that it doesn't exist. I've reinstalled all options with mingw or gcc or g++ remotely in their name in cygwin.
Does anybody know how to get it to compile from the makefile to produce a .lib? Thanks.
I have a following setup. Although my working setup deals with ARM compiler Real View Developer Suite (RVDS) 3.2 on a Windows host, the situation could be generic for any other C compiler on any host.
I build a ARM library (static library - .a file) of C code using RVDS 3.2 compiler toolchain on Windows host. Then I link this library with an application using an ARM-Linux compiler toolchain on a Linux host, to get a ARM executable. Now when I try to debug this generated ARM executable on Linux using gdb, by trying to put a breakpoint in some function which is present in the library that is linked, gdb is not able to put breakpoint there citing source not found. So I manually copied all the source files(*.c) used to create the library in the Linux folder where the executable file is present. Still gdb fails to put a breakpoint.
So now I started thinking:
How can I do source level debugging of this library which I create on Windows using a different compiler chain by launching the executable which is generated by linking this library to an application, in gdb. Is it possible? How can I do it? Is there any compiler option in RVDS compiler toolchain to enable this library source level debug?
Do I need to copy the source files to linux in exactly same folder structure as that is present in windows for those source files?
You could try to see if mimicking the exact same directory structure works. If you're not sure what directory structure the compiler annotated in the debug info in the executable, you can always look at it with dwarfdump (on linux).
First, GDB does not need any source to put breakpoints on functions; so your description of what is actually happening is probably inaccurate. I would start by verifying that the function you want to break on is actually there in the binary:
nm /path/to/app | grep function_desired
Second, to do source level debugging, GDB needs debug info in a format GDB understands. On Linux this generally means DWARF or STABS. It is quite possible that your RVDS compiler does not emit such debug info; if so, source level debugging will not be possible.
Did you build the library with debugging enabled (-g option)? Without that, there would be difficulties identifying lines etc.
I've found that -fPIC will cause this sort of issue, but the only work around I've found is to not use -fPIC when I want to debug.