I am on a Debian linux build environment and cannot change this. We build our apps using mingw and would like to use the openssl suite of tools in one of our applications. The linux version contains the includes openssl/md5.h and compiles gcc with the -lcrypto flag and works great.
What do I need to do to build the Windows dll using mingw and include openssl?
My build command looks like this
x86_64-w64-mingw32-gcc -shared -s FILE.c FILE.def -lcrypto -lws2_32 -o OUT.dll
This produces the error fatal error openssl/md5.h no such file or directory.
I have tried to add the -I /path/to/openssl/includes
Then get the ld error cannot find -lcrypto. I have the libssl-dev libraries.
I have the source for openssl and have tried to compile it using mingw as some other articles have suggested. "cannot find -lcrypto -lssl" with OpenSSL on Windows with MinGW
But the build always fails with multiple files missing the include bits/libc-header-start.h. My thinking was if I can get the windows dlls on the linux system maybe that was what mingw needed.
I have tried to install gcc-multilib as suggested in this post "fatal error: bits/libc-header-start.h: No such file or directory" while compiling HTK but that leads to a basket of missing dependencies.
Is it even possible to build a Windows dll including openssl dependencies from a Debian dev environment?
Thanks for any assistance.
Related
I am building a web server using the libwebsockets library on a TS-7800 board using the arm-linux-gcc cross compiler. Using Ubuntu. Installed CMake, OpenSSL, and libwebsockets and built the library per the instructions on Github.
I made a "hello world" C file which #includes libwebsockets.h
When I compile the executable with gcc, it compiles fine and the .exe runs.
When I compile with arm-linux-gcc, I get the following:
root#gordon-MS-7A39:/# arm-linux-gcc -o hellosockets /home/gordon/workspace/HelloCrossWorld/hello_cross.c
/home/gordon/workspace/HelloCrossWorld/hello_cross.c:3:27: libwebsockets.h: No such file or directory
It appears that arm-linux-gcc compiler cannot "see" the header file for libwebsockets. I'm guessing that the installation of the websockets library was successful because gcc can see it.
How do I enable the arm cross compiler to see the libwebsockets.h file?
Thank you for your input!
You'll need to add armhf architecture to your package management system. Perform the following actions as super user:
dpkg --add-architecture armhf
apt update
apt install libwebsockets-dev:armhf
Make sure you're also using the armhf toolchain:
apt install binutils-arm-linux-gnueabihf g++-arm-linux-gnueabihf
Alternatively, take a look at Buildroot
I was unaware of the -I and -L preprocessor options for gcc and arm-linux-gcc.
I was able to add libraries to the project and will look into creating makefiles for the project.
I've installed
sudo apt-get install libbluetooth-dev
to have bluetooth package in my environment.
Hence, using the following command can successfully compile the bluetooth code using gcc.
gcc -o bt bt.c -lbluetooth
However, when I tried to use the cross-compiler to compile the source code
$CC -o bt2 bt.c -lbluetooth
I got the fatal error:
fatal error: bluetooth/bluetooth.h: No such file or directory
compilation terminated
Is there anything I've done wrong or I need to link this library to this cross-compiler ?
Thanks
I guess your cross compiler comes with a complete toolchain and SDK.
You must check that e.g. libBluetooth.so installed into your SDK under /usr/lib or /usr/local/lib folders and the correct header, as the one installed for i386/x64 platform, is present into SDK.
In case of the header and lib exist you must change your #include into your code to match the path into your SDK.
I have a problem while compiling Vim 7.4 under AIX 6.1.
My options for the configure script are: "--prefix /opt/freeware/bin" and "--enable-pythoninterp".
There where no Errors while running the configure Script but when I try to run "make" I get the error message:
cd src && make first
cc -qlanglvl=extc89 -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -DFUNCPROTO=15 -g -o objects/regexp.o regexp.c "regexp_nfa.c"
line 4410.1: 1506-046 (S) Syntax error.
make: 1254-004 > The error code from the last command is
1.
Stop. make: 1254-004 The error code from the last command is 2.
Stop.
Does anyone know what to do?
I had compiled Vim 7.4 in my home directory so I know that there is a workaround but I can't find it anymore.
AIX's built in make (based on standard AT&T make) is not compatible with the Makefiles built by autoconf tools. Use GNU make (gmake) instead. You may already have it installed (check /opt/freeware/bin), install from the Linux Toolbox for AIX set (from IBM), or from one of the websites providing prebuilt GNU tools for AIX systems (perzl, bullfreeware, etc). Just provide an alias from make to gmake, or override the use of make in the Makefile itself.
I'd like to implement some features of libgcrypt in my program, but it is currently running on Windows, OSX, and Linux (Arch/Xubuntu), so I can only really do so if I can build it for all three platforms. On OSX and Linux I had no problem.
I got the sources from the github page for libgcrypt and libgpg-error, and I've successfully built and run the libraries on both Linux and OSX, so I know that my test code is valid (which I am now having trouble with on Windows w/MinGW).
I did the following on Xubuntu (and similar on Arch but using pacman instead of apt-get):
sudo apt-get install mingw32 mingw32-runtime mingw32-binutils
to get the cross compiling tool chain and
git clone https://github.com/Chronic-Dev/libgcrypt.git
git clone https://github.com/Chronic-Dev/libgpg-error.git
cd libgpg-error
autoreconf -vfi
./autogen.sh --build-w32
make
sudo make install
cd ../libgcrypt
autoreconf -vfi
./autogen.sh --build-w32
make
sudo make install
to build, and it successfully builds these files in home/myuser/w32root/:
libgcrypt.a
libgcrypt.def
libgcrypt.dll.a
libgcrypt.la
libgpg-error.dll.a
libgpg-error.la
include/
gcrypt.h
gcrypt-module.h
gpg-error.h
I took these files over to windows, and tried compiling the test code (named main.c locally) with
gcc main.c -o main.exe -lgcrypt
but I get undefined reference errors leading me to the conclusion that the library wasn't linked correctly (initially only using libgcrypt.a), so I looked some stuff up, and found that some libraries require a set of files like .a, .def, et al. to work, so I dropped them all in C:\Mingw\lib to see if it made a difference; it didn't. The following was also silent in finding the library file to link, but didn't resolve the undefined references:
gcc main.c -o main.exe -lgcrypt -lgpg-error
So I'm not really sure where to go from here. The readme doesn't get into cross compiling too much, like what files to copy and link once you're on the Windows side. Any pointers (to docs for it I missed maybe?) are appreciated! Thanks a bunch for reading my wall of text.
C:\slite\1.1>gcc -c ".\src\SDR.c" -o ".\obj\SDR.o" -I".\inc"
C:\slite\1.1>gcc ".\obj\SDR.o" -o ".\exe\SDR.exe" -L".\lib" -lsres -lshis
.\lib/sres.dll: file not recognized: File format not recognized
collect2: ld returned 1 exit status
Could not compile C program using gcc after installing cygwin in Windows 2003.
Before installing cygwin, I was able to compile successfully.
I am compiling the code from Command prompt, not from cygwin terminal.
The gcc being used is from Dev-Cpp distribution.
Is the problem because of the directory separator ('/') between the libraries directory specified by -L and individual libs specified by -l, being used by gcc after cygwin was installed?
If i try to compile in cygwin terminal I am getting unknown function calls error, though the functions are defined in the headers included.
EDIT:
C:\srmlite\x7.5.0.146-1600>where gcc
C:\Dev-Cpp\bin\gcc.exe
The gcc was not from cygwin.
I have uninstalled cygwin and removed its directory too. I still see this problem.
Try to add the correct bin directory into the path in your Environment variables.
Something like this: C:\soft\cygwin\bin
Seems that Cygwin modified the default environment, adding itself to %PATH%, so you're actually calling cygwin's gcc, check that out.