I have pre-existing code that was written and is running on a Linux machine. I need to add to this code, this new code which depends on a library using VS. I have decided to develop on Visual Studio using WSL (Windows Subsystem for Linux) then taking the executable/out file to my Linux machine and running it there.
The code I am adding myProg.c uses a function Func(double arg) which comes from the library Reallib.lib
I have included the header file
#include "Support_Files/Reallib.h"
In my project property pages, the .lib file is in the Additional Dependencies
Support_Files/Reallib.lib
The declaration in the Reallib.h file:
long Func(double arg)
At build-time, these are the errors I get:
/mnt/c/Users/mitch/Projects/myproject/myproject/myproject/obj/x64/Debug/myProg.c: in function `main':
undefined reference to Func
ld returned 1 exit status
If I'm including my library already, why am I getting this error? Is it because Linux systems don't use .lib files? How can I combine the code written on Windows with code written on Linux?
Researching online doesn't seem to match my similar problem.
I have already tried using GCC for Remote Linux, but a similar error was produced. But neither (WSL or Remote Linux) seem to play nice with combining .lib files with source code written on Linux.
Now, I could add RealFunc.c and that would clear the error up, but I would just get another undefined reference error, and so on and so forth (RealFunc.c has plenty of other dependencies that are taken care of in Reallib.lib)
Configuration properties > General > Platform Toolset
I've also tried developing only on Linux, bringing the .lib file over and updating my makefile to link that, but it wasn't working (I believe because Linux doesn't use .lib)
What should be my route of action? I NEED the code that is in Reallib.lib. Do I need to bite the bullet and essentially recompile all the source code in Reallib.lib? Do I need to just move over to Linux 100% and use VS Code? I like using VS because it makes the compiling and linking options much easier. I am still new to C and Linux.
I am using Visual Studio 2022 17.4.3
WSL Ubuntu (v20.04)
$ gcc --version
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
There is no proper/native way to use a Windows library .lib in Linux, your only solution is by re-compiling the library for the targeted platform, in this case, is Linux.
Option A
Simply re-compile the library source code in Linux using GCC or Clang to generate the proper .a static library or .so shared library.
Option B
Install a cross compiler in Windows for Linux, you can use Cygwin if you are familiar with it.
Related
Is it possible to build GMP for MSVC on Windows?
I need fully static solution (static library), without any DLL dependencies. So that my final EXE doesn't depend on any external (non-system) DLLs.
I'm alright if building GMP will need Cygwin or MSYS, as far as it can be used later in MSVC without any problems. But as far as I know at least Cygwin builds always depend on extra DLLs like cygwin1.dll which is not affordable for me, fully static-library solution is needed.
I'm aware there exists MPIR library that is more Windows friendly. But right now I need specifically GMP solution if possible.
Of course would be great if all optimizations and assembly is used when building for Windows. But if assembly is not possible then at least non-assembly (generic) variant of GMP is needed.
Of course I need 64-bit version.
If someone can post all steps needed to produce such static library for MSVC usage? Or maybe link some web-site that has such instructions?
I successfully managed to compile a working fully statically linked program with GMP using MSVC under Windows.
For that I used installation of MSYS, which is located in c:/bin/msys/ on my machine.
Then inside MSYS shell installed GMP packages mingw-w64-clang-x86_64-gmp and gmp-devel (pacman -S gmp-devel to install and pacman -Ss gmp to search).
In MSVC compiler I added include directory c:/bin/msys/clang64/include/.
Wrote an example of GMP usage program in C++, that implements Trial Division / Pollard's Rho / Pollard's P-1 factoring algorithms using long arithmetics. This program uses both mpz_...() C routines and mpz_class C++ wrapper class. For example this program is located in main.cpp.
To linker command line I added following libraries:
c:/bin/msys/clang64/lib/libgmp.a
c:/bin/msys/clang64/lib/libgmpxx.a
c:/bin/msys/mingw64/lib/gcc/x86_64-w64-mingw32/10.3.0/libgcc.a
c:/bin/msys/clang64/x86_64-w64-mingw32/lib/libmingwex.a
Also I had to add /FORCE flag (read about it here) to linker command, because libmingwex.a has some symbols overlapping with default MSVC's libraries, precisely without /FORCE I had following errors:
libucrt.lib(strnlen.obj) : error LNK2005: wcsnlen already defined in libmingwex.a(lib64_libmingwex_a-wcsnlen.o)
libucrt.lib(strnlen.obj) : error LNK2005: strnlen already defined in libmingwex.a(lib64_libmingwex_a-strnlen.o)
bin\win-msvc-m-64-release\drafts\gmp_int_msvc.exe : fatal error LNK1169: one or more multiply defined symbols found
All steps produced working (tested) final statically-linked program without any external DLL dependencies (of course except for default system DLLs of Windows).
It means MSYS's libraries .a are fully compatible with MSVC and link successfully in MSVC compilation.
Not to have /FORCE linker flag I also did extra following steps. Made a copy of c:/bin/msys/clang64/x86_64-w64-mingw32/lib/libmingwex.a library. Used c:/bin/msys/clang64/bin/objcopy.exe util, which probably was installed together with Clang. With objcopy renamed overlapping symbols:
objcopy --redefine-sym wcsnlen=msys_wcsnlen libmingwex.a
objcopy --redefine-sym strnlen=msys_strnlen libmingwex.a
which allowed me to successfully use this modified libmingwex.a library to link in MSVC without using /FORCE.
I am trying to compile native linux c files on windows using GNU GCC compilers. For the installation purpose, I have followed the steps mentioned by Faheem in the following link :
Using GCC(minGW) as Matlab's MEX compiler
the example given there compiled successfully. but when i am trying to compile a file using thread functions, the following error is being thrown:
fatal error: pthread.h: No such file or directory
#include
^
compilation terminated.
I have installed all the components from MinGW installer related to GNU C compiler bu still the error persists. Can any one suggest a way to solve this problem. Thanks in advance.
According to the TDM-GCC "Quircks" page, TDM-GCC includes a pthreads emulation layer for Microsoft Windows systems, called "winpthreads", and a recent toolchain you should have x86_64-w64-mingw32\include\pthread.h in the TDM install path. So, I don't know what is wrong with Faheem's instructions, but you should have no trouble including pthread.h if MATLAB is configured correctly.
What is not stated on the TDM Quircks page is that TDM uses Winpthreads from the MinGW-w64 project. From the current README installed with TDM:
"Winpthreads" is one of the libraries distributed by the MinGW-w64 project, and
it allows GCC to be compiled with full pthreads compatibility, which is
necessary to enable std::thread and other threading related functions in the
C++ runtime.
As it states, Pthreads is part of the MinGW-w64 project and you can also get it with MinGW-w64 if you pick a pthreads enabled toolchain. For MinGW-w64, I do the following to set it up (see here for more details):
Grab the latest revision for w64 from Sourceforge (or use the installer to choose the toolchain you want, picking a pthread version).
Extract it so that you have a path to the compiler like C:\mingw-w64\x86_64-4.9.2-release-posix-seh-rt_v3-rev1\bin\x86_64-w64-mingw32-g++.exe. There is no need for MSYS, cygwin, or any other environment if you plan on compiling in MATLAB with mex.
Set it up with a custom mexopts.bat or using the new xml configuration system. On my GitHub repo, I have C++ configurations for MinGW-w64 in both file types: mingw_mexopts.bat and mex_C++_mingw-w64.xml. For example, using the xml file to set up C++ MEX file compilation:
mex -setup:C:\Users\Jon\Documents\MATLAB\mex_C++_mingw-w64.xml C++
If needed, set up the C compiler in a similar manner by modifying the config files.
I posted a more detailed version of the above instructions in my answer to the canonical question on the MinGW-with-MATLAB topic.
I am writing some code for raspberry pi ARM target on x86 ubuntu machine. I am using the gcc-linaro-armhf toolchain. I am able to cross compile and run some independent programs on pi. Now, I want to link my code with external library such as ncurses. How can I achieve this.
Should I just link my program with the existing ncurses lib on host machine and then run on ARM? (I don't think this will work)
Do I need to get source or prebuilt version of lib for arm, put it in my lib path and then compile?
What is the best practice in this kind of situation?
I also want to know how it works for the c stdlib. In my program I used the stdio functions and it worked after cross compiling without doing anything special. I just provided path for my arm gcc in makefile. So, I want to know, how it got correct std headers and libs?
Regarding your general questions:
Why the C library works:
The C library is part of your cross toolchain. That's why the headers are found and the program correctly links and runs. This is also true for some other very basic system libraries like libm and libstdc++ (not in every case, depends on the toolchain configuration).
In general when dealing with cross-development you need some way to get your desired libraries cross-compiled. Using binaries in this case is very rare. That is, especially with ARM hardware, because there are so many different configurations and often everything is stripped down much in different ways. That's why binaries are not very much binary compatible between different devices and Linux configurations.
If you're running Ubuntu on the Raspberry Pi then there is a chance that you may find a suitable ncurses library on the internet or even in some Ubuntu apt repository. The typical way, however, will be to cross compile the library with the specific toolchain you have got.
In cases when a lot and complex libraries need to be cross-compiled there are solutions that make life a bit easier like buildroot or ptxdist. These programs build complete Linux kernels and root file systems for embedded devices.
In your case, however, as long as you only want ncurses you can compile the source code yourself. You just need to download the sources, run configure while specifying your toolchain using the --host option. The --prefix option will choose the installation directory. After running make and make install, considering everything went fine, you will have got a set of headers and the ARM-compiled library for your application to link against.
Regarding cross compilation you will surely find loads of information on the internet and maybe ncurses has got some pointers in its shipped documentation, too.
For the query How the C library works in cross-tools
When compiling and building cross-tool chain during configuration they will provide sysroot.
like --with-sysroot=${CLFS_CROSS_TOOLS}
--with-sysroot
--with-sysroot=dir
Tells GCC to consider dir as the root of a tree that contains (a subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched for in there. More specifically, this acts as if --sysroot=dir was added to the default options of the built compiler. The specified directory is not copied into the install tree, unlike the options --with-headers and --with-libs that this option obsoletes. The default value, in case --with-sysroot is not given an argument, is ${gcc_tooldir}/sys-root. If the specified directory is a subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved.
So instead of looking /lib /usr/include it will look /Toolchain/(libc) and (include files) when its compiling
you can check by
arm-linux-gnueabihf-gcc -print-sysroot
this show where to look for libc .
also
arm-linux-gnueabihf-gcc -print-search-dirs
gives you clear picture
Clearly, you will need an ncurses compiled for the ARM that you are targeting - the one on the host will do you absolutely no good at all [unless your host has an ARM processor - but you said x86, so clearly not the case].
There MAY be some prebuilt libraries available, but I suspect it's more work to find one (that works and matches your specific conditions) than to build the library yourself from sources - it shouldn't be that hard, and I expect ncurses doesn't take that many minutes to build.
As to your first question, if you intend to use ncurses library with your cross-compiler toolchain, you'll have its arm-built binaries prepared.
Your second question is how it works with std libs, well it's really NOT the system libc/libm the toolchain is using to compile/link your program is. Maybe you'll see it from --print-file-name= option of your compiler:
arm-none-linux-gnuabi-gcc --print-file-name=libm.a
...(my working folder)/arm-2011.03(arm-toolchain folder)/bin/../arm-none-linux-gnuabi/libc/usr/lib/libm.a
arm-none-linux-gnuabi-gcc --print-file-name=libpthread.so
...(my working folder)/arm-2011.03(arm-toolchain folder)/bin/../arm-none-linux-gnuabi/libc/usr/lib/libpthread.so
I think your Raspberry toolchain might be the same. You can try this out.
Vinay's answer is pretty solid. Just a correction when compiling the ncurses library for raspberry pi the option to set your rootfs is --sysroot=<dir> and not --with-sysroot . Thats what I found when I was using the following compiler:
arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I want to build a static library (*.LIB file) GNU libiconv on windows to be used with other libraries in Visual C++. Other libraries I'm using are built with "MultiThreaded DLL" (/MD) Runtime option. So, I need to build libiconv with the same option.
Problem is the libiconv uses GNU build system and I want to compile with /MD option. You can see the source structure of libiconv here:
http://cvs.savannah.gnu.org/viewvc/libiconv/?root=libiconv
Mr. Zlatkovic maintains the windows port of GNU libiconv for libxml2
you can see them here:
ftp://xmlsoft.org/libxml2/win32/iconv-1.9.2.win32.zip
I cannot use his port. I need to build from the latest version of libiconv-1.13. I wonder how this guy has ported it? Can some one please tell me how to build *.lib from this and compile it using MSVC?
EDIT:
Actually, I need to build few more gnu libraries with same settings. So, if I get solution for one library. I can do the same for all others.
I found PARK Youngho's How to Build libiconv with Microsoft Visual Studio over at The Code Project to be complete and clean (for VS2010 and GNU libiconv 1.14).
A little addition to your answer.
I had the same issue and found that the MinGW + MSYS solution was perfect.
Though, I needed to go a little further and generate also the .lib file in order to be able to link with the resulting dll.
This is what I found:
generate a .def file from the dll with dumpbin (a Visual Studio tool).
generate the .lib file from the .def with the lib program (Visual Studio tool too)
This allows you to specify some link flags if appropriate.
Everything detailed here (I'm not the author of this method):
http://wiki.videolan.org/GenerateLibFromDll
I also realized that this lib/dll couple can be linked with both MD and MDd libraries.
Hope that can help people that find this post, like it helped me.
-David
I'm the OP. MSYS is the exact thing what I was looking for.
Just install MinGW & MSYS which contains shell sh.exe & make.exewith which you can configure and generate a Makefile after that you can use make.exe to run it.
Its as simple as that.
compile them using MinGW using Msys for the environment if needed. MinGW's .a files are apparently, according to the mailing list, the same format as .lib files (just do a rename). You might want to check first to see if the iconv static library is included already in the MinGW download / filesystem.
Edit: it's in msys (C:\msys\1.0\lib), along with:
libiconv.a
libiconv.dll.a
libiconv.la
and additionally
libiconv-2.dll (in C:\msys\1.0\local\bin)
Edit: is it in here, the libiconv you need? these versions seem to have MSVC makefiles :) http://www.opensource.apple.com/source/libiconv/
I haven't done C in a long time. I'd like to compile this program, but I have no idea how to proceed. It seems like the makefile refers to GCC a lot and I've never used GCC.
I just want an executable that will run on windows.
You may need to install either cygwin or mingw, which are UNIX-like environments for Windows.
http://www.mingw.org/
http://www.cygwin.com/
When downloading/installing either cygwin or mingw, you will have the option of downloading and installing some optional features; you will need the following:
gcc (try version 2.x first, not 3.x)
binutils
GNU make (or gmake)
If it requires gcc and you want it to run on Windows, you could download Cygwin.
That's basically an emulator for GNU/Linux type stuff for Windows. It works with an emulation DLL.
http://www.cygwin.com/
In order to compile this program you need a C compiler. It does not have to be gcc, although you are already given a makefile set up to use gcc. The simplest thing for you to do would be the following:
Install cygwin
Open the cygwin command prompt
go into the directory where you have your makefile
type 'make'
That should compile your program
If you are not comfortable with using command line tools then you can download the free version of MS Visual Studio and import the source files into a new Visual Studio project. This way you would not need to install cygwin and use gcc, but you would need to know how to create projects and run programs in Visual Studio.
You almost certainly don't need all of cygwin to compile using gcc. There are plenty of standalone gcc clones for Windows, like gcw.
If it's reasonably portable C code (I haven't looked at it), then you may be able to just ignore the included Makefile and feed the source into whatever compiler you do want to use. What happens when you try that?
Dev-C++ provides a simple but nice IDE which uses the Mingw gcc compiler and provides Makefile support. Here are the steps I used to build the above code using Dev-C++ (i.e. this is a "how-to")
After downloading the source zip from NIST, I
downloaded and installed the Dev-C++ 5 beta 9 release
created a new empty project
added all the .c files from sts-2.0\src
Then under Project Options
added -lm in the Linker column under Parameters
added sts-2.0\include to the Include Directories in Directories
set the Executable and Object directories to the obj directory under the Build Options
and then hit OK to close the dialog. Go to Execute > Compile and let it whirl. A minute later, you can find the executable in the sts-2.0\obj directory.
First, there is little chance that a program with only makefiles will build with visual studio, if only because visual studio is not a good C compiler from a standard POV (the math functions in particular are very poorly supported on MS compilers). It may be possible, but it won't be easy, specially if you are not familiar with C. You should really stick to the makefiles instead of trying to import the code in your own IDE - this kind of scienfitic code is clearly meant to be compiled from the command line. It is a test suite, so trying things randomly is NOT a good idea.
You should use mingw + msys to install it: mingw will give you the compilers (gcc, etc...) and msys the shell for the make file to run correctly. Contrary to one other poster, I would advise you against using gcc 2 - I don't see any point in that. I routinely use gcc 3 (and even 4) on windows to build scientific code, it works well when the code is unix-like (which is the standard platform for this kind of code).