I can currently compile C programs with stdio.h and such like for Windows with the command i586-mingw32msvc-gcc, however I cannot do this for a GLUT program. When compiling it for Linux I use:
gcc main.c -lglut -lGLU
(I know, bad practice as it comes out with a.out)
Yet I am unsure of how I could do it for Windows using mingw32. When I run
i586-mingw32msvc -lglut -lGLU
it returns:
test.c:3:21: error: GL/glut.h: No such file or directory
The included header files are:
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>
And I am unsure of how to make it able to compile. Any ideas?
Essentially that error tells you, that your MinGW GCC does not find the required headers. That is, because you're cross-compiling to another OS, and header files may contain OS specific things. Unfortunately OpenGL is one of those. So you have to install the required libraries in a Windows version as well.
However you should not just download some precompiled binaries from the web; you need libraries matching MinGW. You can of course install MinGW built libraries, that will work. However I suggest something different: Crosscompile and locally install all the libraries you require in your MinGW environment yourself. You do this, by passing the right compiler, linker and prefixes into the build configuration of each library. For example for autoconf based configure (on my system)
CC=i686-mingw32-gcc CXX=i686-mingw32-g++ ./configure --prefix=/usr/i686-mingw
make ; make install will then build and install the libraries and their headers in the MinGW environment, where you can use them as any other regular installed library.
Related
I am building a simple command line game in C using the ncurses library on a Linux machine but I want to be able to run the compiled code on a Windows computer. To do this, I am using the MinGW-w64 cross compiler tool in Linux and compiling it to run in a 64 bit Windows environment. However, when I try to compile using this command:
x86_64-w64-mingw32-gcc -o game.exe barebones.c -lncurses
I get this error:
barebones.c:2:10: fatal error: ncurses.h: No such file or directory
2 | #include <ncurses.h>
| ^~~~~~~~~~~
compilation terminated.
I installed ncurses on my Ubuntu machine and can create and run the same simple program to run on Linux. I have been able to cross-compile and run simple programs that only use the default libraries. I think I must be listing the ncurses library incorrectly in the compliation command or that I am failing to understand other posts that show that this doesn't work.
I am using Windows 10 and Ubuntu 21.04.
Debian provides no cross-compiling packages for ncurses. (Ubuntu provides no additions or improvements to ncurses in any way, simply reusing packages from Debian). If you want to cross-compile ncurses, you'll have to build ncurses in cross-compiling form.
For development purposes, ncurses packages can be built using the scripts under the (sources) packages directory, e.g., after downloading the current source:
tar xf ncurses-whatever.tgz
cd ncurses-whatever
cp -var packages/debian-mingw64 ./debian
dpkg-buildpackage
That's a starting point. You'd have to do something about the email in the debian/control file to appease dpkg-buildpackage (tutorials are off-topic).
So I've been reading online but I'm still very confused. I understand that there are different tools in the Linux-on-Windows world: Msys, Msys2, Cygwin, Mingw and Mingw-64.
Here is what I think I know, and please correct me if I'm wrong:
Mingw aims to simply be a port of the GCC programs to Windows. It creates native Windows binaries and that's it.
Mingw-64 is just a more recent and better supported version of Mingw that also supports Windows 64 bit.
Cygwin, while also including Mingw (?) to support GCC on Windows, provides a POSIX compatibility layer through a DLL that all programs are linked to by default.
MSYS is a fork of Cygwin, but it drops some of the POSIX compatibility efforts. Instead it mostly aims to allow creating native Windows program. But - they will still be dependent on a MSYS DLL being present.
MSYS2 is just a more recent and active version of the less active MSYS.
Is this all true? If it is, here is what I want to validate:
Essentially, I think all I should need for my development is Mingw in order to use GCC to build native Windows applications. I don't need a POSIX layer, and I don't want my program to depend on any DLL apart from the ones that are present on Windows systems anyway. As far as I understand, this is what Mingw offers.
However, somehow I managed to install MSYS (or MSYS2? I'm not sure anymore) on my system. The tutorial I was following early on suggested doing so.
Since it seems MSYS(2) includes Mingw under C:\msys64\mingw64, I just use the Mingw binaries directly from the Windows CMD without going through the MSYS(2) shell program. For example, I just added C:\msys64\mingw64\bin to the PATH and I run gcc from the Windows CMD directly to compile my project.
Is this a valid way to use Mingw? Or am I expected to run into problems?
Does this approach create pure Windows native binaries which should never depend on any MSYS(2)-related DLL?
Is it true that the MSYS(2)-related functionality and dependencies only come into play if I launch the Mingw programs (such as GCC) through the msys2.exe shell program? And so if I want to avoid any MSYS(2) or Cygwin related stuff, and simply use pure Mingw GCC, is it an okay approach to just launch GCC directly under the Mingw directory as described earlier?
Update: I have now checked using Dependency Walker, and running C:\msys64\mingw64\bin\gcc from the MSYS2 shell still creates an .exe with no special dependencies (which is good). So what is this msys-2.0.dll that the MSYS2 docs speak of? And how is using MSYS2 to compile C different than just using Mingw?
You're mostly right about what these projects are. MSYS2 does provide an evironment for POSIX programs like Bash, GNU Make, and other utilities, but it also provides a package manager named pacman that you can use to install lots of other things. In fact, you can use pacman to install a mingw-w64 toolchain.
MSYS2 provides two mingw-w64 toolchains actually: you get a choice of an i686 (32-bit) toolchain which makes native Windows binaries that can run on any Windows computer, or an x86_64 (64-bit) toolchain that makes native Windows binaries that only work on 64-bit Windows. You can install both of these at the same time.
You say "I don't need a POSIX layer", but you might find it useful to be able to write Bash scripts or use POSIX programs provided by MSYS2 like GNU Make when building your native Windows software. This is especially useful if you want to someday build your software on Linux or macOS: it's possible to write a simple Makefile or shell script that works on those platforms and also MSYS2.
Yes, it's valid to use the binaries from C:\msys64\mingw64\bin directly if you want to.
Yes, the mingw-w64 toolchain creates native Windows binaries regardless of which shell you happen to run it from.
No. Whether you start MSYS2 via msys2.exe, mingw32.exe, or mingw64.exe, you get a Bash shell with various Linux utilities available like ls, grep, make, and tar. The shell and those utilities use the POSIX emulation provided by msys-2.0.dll. The main difference between those MSYS2 launchers is what gets added to your PATH, so you might want to run echo $PATH and env in each of those environments and compare the results.
I'd strongly recommend using MSYS2 instead of MSYS and mingw.org . Pretend those latter two don't even exist. Being under active development the newer projects are better in every way.
MSYS2's package manager can deliver toolchains for the following target systems:
Standalone Win32 (i686)
Standalone Win64 (x86_64)
MSYS2 i686
MSYS2 x86_64
The former two cases can be invoked from any shell you like. You may need to set up paths if not using the launch script provided by MSYS2. They produce native Windows executables. Using the default switches to GCC there will be some dependencies, such as libgcc_s*.dll . Doing a static build with -static will produce an executable with no dependencies other than Windows DLLs.
In the latter two cases, the binary will depend on the MSYS2 DLL, and other things, but this provides support for a range of POSIX functionality.
[~ MSYS]$ ls /usr/include
_ansi.h cursesp.h glob.h net strings.h
_newlib_version.h cursesw.h gnumake.h netdb.h symcat.h
_syslist.h cursslk.h grp.h netinet sys
a.out.h cygwin icmp.h newlib.h sysexits.h
acl devctl.h ieeefp.h nl_types.h syslog.h
aio.h diagnostics.h ifaddrs.h panel.h tar.h
alloca.h dirent.h inttypes.h paths.h term.h
alpm.h dis-asm.h io.h plugin-api.h term_entry.h
alpm_list.h dlfcn.h langinfo.h poll.h termcap.h
ansidecl.h elf.h lastlog.h process.h termio.h
ar.h endian.h libfdt.h pthread.h termios.h
argz.h envlock.h libfdt_env.h pty.h tgmath.h
arpa envz.h libgen.h pwd.h threads.h
asm err.h limits.h reent.h tic.h
assert.h errno.h locale.h regdef.h time.h
attr error.h machine regex.h tzfile.h
bfd.h eti.h magic.h resolv.h ucontext.h
bfd_stdint.h etip.h malloc.h sched.h unctrl.h
bfdlink.h fastmath.h mapi.h search.h unistd.h
bits fcntl.h math.h semaphore.h utime.h
byteswap.h fdt.h memory.h setjmp.h utmp.h
complex.h features.h menu.h signal.h utmpx.h
cpio.h fenv.h mntent.h spawn.h w32api
ctf.h FlexLexer.h monetary.h ssp wait.h
ctf-api.h fnmatch.h mqueue.h stdatomic.h wchar.h
ctype.h form.h nc_tparm.h stdint.h wctype.h
curses.h fts.h ncurses stdio.h winpty
cursesapp.h ftw.h ncurses.h stdio_ext.h wordexp.h
cursesf.h gawkapi.h ncurses_dll.h stdlib.h xlocale.h
cursesm.h getopt.h ncursesw string.h
[~ MSYS]$
[~ MSYS]$
[~ MSYS]$ ls /usr/include/sys
_default_fcntl.h acl.h fcntl.h mman.h quota.h signal.h stdio.h termio.h ttychars.h utsname.h
_intsup.h cdefs.h features.h mount.h random.h signalfd.h strace.h termios.h types.h vfs.h
_pthreadtypes.h config.h file.h msg.h reent.h smallprint.h string.h time.h ucontext.h wait.h
_sigset.h custom_file.h iconvnls.h mtio.h resource.h socket.h sysinfo.h timeb.h uio.h xattr.h
_stdint.h cygwin.h ioctl.h param.h sched.h soundcard.h syslimits.h timerfd.h un.h
_timespec.h dir.h ipc.h poll.h select.h stat.h syslog.h times.h unistd.h
_timeval.h dirent.h kd.h procfs.h sem.h statfs.h sysmacros.h timespec.h utime.h
_types.h errno.h lock.h queue.h shm.h statvfs.h sysproto.h tree.h utmp.h
Cygwin is a competing product also providing POSIX functions and depending on a Cygwin DLL. The MSYS2 target is a fork of Cygwin.
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 have code::blocks and a spare evening, would like to put my hands on vulkan. Now on windows 7.
I'm having troubles finding any documentation/tutorials nor the libraries to work in codeblocks. I have glfw 3.2 but it requires a vulkan library and headers as well to work with it (#define GLFW_INCLUDE_VULKAN) otherwise it rightfully complains about a missing vulkan/vulkan.h. Also installed LunarG, but can't find any recognizable libraries in the package that i could link via the linker settings in the usual way.
My code right now is straightforward:
...
#include <GL/glu.h>
#define GLFW_INCLUDE_VULKAN
#include <GLFW/glfw3.h>
int main(int argc, char **argv) {
glfwInit();
return glfwVulkanSupported();
}
with -lglu32 -lglfw3 -lopengl32 -lgdi32
Basically all i think i need is a library to link to but can't find any on the web.
Using the old GLU library may not be a good idea with Vulkan
Instal the LunarG SDK.
Set additional include directory in your IDE project: $VULKAN_SDK/Include (VULKAN_SDK is an env variable with a path to root of the SDK).
Do not link against OpenGL if you are only going to use Vulkan.
Code::Blocks is g++ or clang based right? Link against the vulkan-1.dll. -lvulkan-1 should suffice, because the path should be in PATH. Otherwise provide the path with -L — it is in $WINDIR/System32 (for x64 and x32 OS) and in $WINDIR/SysWOW64 (for x32 app on x64 OS).
vulkan-1.dll is installed there by drivers and by the SDK also.
I am trying to run someone else's (4 year old) code from sourceforge. I downloaded cygwin and checked out the project with CVS.
Here is the compile line which is failing:
gcc ../block_display/block_display.c -o block_display -lopengl32 -lglut32 -lm
Here is the relevant include statement in block_display.c:
#include <GL/glut.h>
When I try to run the above compile line, I get this compile error:
$ gcc ../block_display/block_display.c -o block_display -lopengl32 -lglut32 -lm
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lglut32
collect2: ld returned 1 exit status
I admit I am new/rusty with cygwin. I tried a few things to get to this point, but since I don't entirely know where to put files, I am stuck on this error. Here is what I have tried:
Downloading all results for 'glut' in cygwin setup: libglut-devel, freeglut, libglut3
Downloading glut 3.7.6, copying glut32.dll to C:\Windows\SysWOW64, and copying glut.h to C:\cygwin\usr\include. I still have glut.def and glut32.lib sitting around, but I do not know exactly where to place them. I tried following this install guide, but since I am not running VC++, I do not know what the cygwin equivalent of VC++ path is.
Any idea what I could do to get this code to compile successfully? I am running Windows 7 64-bit.
You should use freeglut instead. The original glut is far outdated. Freeglut on the other hand is binary and source compatible with the original glut, and it's also open source.
Since glut32.dll is a windows DLL and cygwin is for emulating a unix environment on windows, you can't easily use the original glut with cygwin without recompiling from source.