Mingw do not find Allegro lib

Mingw do not find Allegro lib

Nuxation

Member #17,744

May 2020

Hello,
I would wish to try to use allegero with mingw on windows 10, so I readed The wiki quick start and followed the instruction, I downloaded "allegro-x86_64-w64-mingw32-gcc-9.2.0-posix-seh-dynamic-5.2.6.0.zip" because it was the same version than the one propose in the Tutorial but up-to-date then I added the bin,include and lib from the .zip extracted to the mingw folder having the same name (as ask in the quickstart).

When I try to run the hello.c from quickstart in powershell, I get those errors.

with gcc

#SelectExpand
 1gcc hello.c -o hello -lallegro -lallegro_font
 2hello.c:1: No include path in which to find allegro5\allegro5.h
 3hello.c:2: No include path in which to find allegro5\allegro_font.h

with g++

#SelectExpand
  1g++ hello.c -o hello -lallegro -lallegro_font
  2d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x21): undefined reference to `al_install_system'
  3d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x26): undefined reference to `al_install_keyboard'
  4d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x34): undefined reference to `al_create_timer'
  5d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x40): undefined reference to `al_create_event_queue'
  6d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x5b): undefined reference to `al_create_display'
  7d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x67): undefined reference to `al_create_builtin_font'
  8d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x73): undefined reference to `al_get_keyboard_event_source'
  9d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x86): undefined reference to `al_register_event_source'
 10d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x95): undefined reference to `al_get_display_event_source'
 11d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0xa8): undefined reference to `al_register_event_source'
 12d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0xb7): undefined reference to `al_get_timer_event_source'
 13d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0xca): undefined reference to `al_register_event_source'
 14d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0xe1): undefined reference to `al_start_timer'
 15d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0xf8): undefined reference to `al_wait_for_event'
 16d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x13e): undefined reference to `al_is_event_queue_empty'
 17d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x176): undefined reference to `al_map_rgb'
 18d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x1a3): undefined reference to `al_clear_to_color'
 19d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x1ca): undefined reference to `al_map_rgb'
 20d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x221): undefined reference to `al_draw_text'
 21d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x226): undefined reference to `al_flip_display'
 22d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x242): undefined reference to `al_destroy_font'
 23d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x251): undefined reference to `al_destroy_display'
 24d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x260): undefined reference to `al_destroy_timer'
 25d:/.../mingw32/bin/ld.exe: C:\...\ccYJ5UyG.o:hello.c:(.text+0x26f): undefined reference to `al_destroy_event_queue'
 26collect2.exe: error: ld returned 1 exit status

I already double check folder and allegro5\allegro5.h and allegro5\allegro_font.h are well named and present in mingw include folder.

I don't know how to solve those error , it would be nice if someone can help me.
I am aware it seem to be an issue more related to mingw than allegro but I feel more likly to interect with allegro community if I start a game with allegro,so I prefered to ask here.

Peter Hull

Member #1,136

March 2001

Can you try:

cpp -v /dev/null

and tell us what it prints, particularly the lines right after

#include <...> search starts here:

Do those lines correspond with where you put allegro's headers?

Nuxation

Member #17,744

May 2020

cpp -v /dev/null
requested me a value for "name" and for "Destination" and I was not sure about how to handle this :S

I hope it will not been taken badly but I tried to interpret your intention (also sorry for my bad wording I am not native).

I have try on an empty foo.c file with this commande: "gcc -v -c foo.c"(Source: http://www.mingw.org/wiki/IncludePathHOWTO)

#SelectExpand
  1gcc -v -c foo.c
  2Using builtin specs.
  3gcc version 2.95 19990728 (release)
  4 cpp -lang-c -v -iprefix C:\FPC\3.0.4\bin\i386-Win32\..\lib/gcc-lib/i386-mingw32\2.95\ -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 
  5-D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___stdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ foo.c C:\...\AppData\Local\Temp\ccuGcaaa.i   
  6GNU CPP version 2.95 19990728 (release) (80386, BSD syntax)
  7#include "..." search starts here:
  8End of search list.
  9The following default directories have been omitted from the search path:
 10 /gcc-2.95/lib/gcc-lib/i386-mingw32/2.95/../../../../include/g++-3
 11 /gcc-2.95/lib/gcc-lib/i386-mingw32/2.95/../../../../include
 12 /gcc-2.95/lib/gcc-lib/i386-mingw32/2.95/../../../../i386-mingw32/include
 13 /gcc-2.95/lib/gcc-lib/i386-mingw32/2.95/include
 14 /usr/local/i386-mingw32/include
 15End of omitted list.
 16 cc1 C:\...\AppData\Local\Temp\ccuGcaaa.i -quiet -dumpbase foo.c -version -o C:\...\AppData\Local\Temp\ccOcfaaa.s
 17gcc.exe: installation problem, cannot exec `cc1': No such file or directory

Does /dev/null work on windows ? (I founded this but maybe this is outdate)

If you was wishing I truly use "cpp -v /dev/null" which value should I give to name and destination please ?

Edit:

Peter Hull said:

Do those lines correspond with where you put allegro's headers?

I don't have those line while it should been here considering what mingw.org say

Edit 2: I tried to re-install MinGW in his default path (C:\MinGW instead of D:\...\Mingw)
But this do not change the result

bamccaig

Member #7,536

July 2006

/dev/null is a special file in Unix-like systems that represents a virtual "device" that is always empty (if you try to read from it you should get nothing, and if you write to it then it goes nowhere). Windows treats the filename NUL as special and it works in a similar way.

If you extracted Allegro directly into the MinGW folder then you shouldn't need any special arguments. There should be C:\MinGW\include\allegro5\allegro5.h, for example. Check that that is true.

Make sure you use / instead of \ in your #include directives:

// E.g.,
#include <allegro5/allegro5.h>

I don't recall if it matters, but it will certainly work with forward slashes (and it's more portable that way, meaning it will also work on other operating systems).

I find it strange that gcc seemed not to find the headers, but g++ did... :-/

Typically your version of gcc needs to match the version that Allegro was built with. That is typically in the name of the distribution of Allegro that you download. In this case, mingw32-gcc-9.2.0. It has been many years since I used MinGW, but the version reported by your gcc command appears to be 2.95... Which is odd because apparently that dates back to 2001. :-/

I'm going to conclude that I am confused and wait for somebody with more recent MinGW experience to chime in...

Don't worry about your English. We have members from all over the world, including other Frenchmen, and your English is very good compared to some.

--
I mean the best with what I say. It doesn't always sound that way.

Nuxation

Member #17,744

May 2020

bamccaig said:

If you extracted Allegro directly into the MinGW folder then you shouldn't need any special arguments. There should be C:\MinGW\include\allegro5\allegro5.h, for example. Check that that is true.

I copy past the 3 folder after extraction, "allegro_deps_version.txt" is not in my MinGW folder.

"C:\MinGW\include\allegro5\allegro5.h" is well here.
{"name":"hfhKJn7.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/a\/ea2daab6c1c4db58548c3381c55e715e.png","w":681,"h":870,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/a\/ea2daab6c1c4db58548c3381c55e715e"}

Quote:

// E.g.,
#include <allegro5/allegro5.h>

Yup, I copy pasted the code from The wiki quickstart
And i double check this is exactly like in the quote

Quote:

I did not realise that I have to use 9.2.0 and that it showed that gcc use 2.95, Thanks.

The MinGW Graphical installer version seems to match for the version I installed.

{"name":"Ahy436E.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/a\/1a4b05e7417184d173339375c785ea30.png","w":1074,"h":311,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/a\/1a4b05e7417184d173339375c785ea30"}

But not from the command, so I am starting to wonder if I could have an other version of MinGW install at a random place on my computer.

I am going to check that. And tell you if I find an other version and/or solve it.

Edit:
I think Double post is not allowed so I will do an edit.

I was indeed having an other version for gcc. It is deleted now, and I get the same issue with gcc and g++

#SelectExpand
  1gcc hello.c -o hello -lallegro -lallegro_font
  2c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x21): undefined reference to `al_install_system'
  3c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x26): undefined reference to `al_install_keyboard'
  4c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x34): undefined reference to `al_create_timer'
  5c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x40): undefined reference to `al_create_event_queue'
  6c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x5b): undefined reference to `al_create_display'
  7c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x67): undefined reference to `al_create_builtin_font'
  8c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x73): undefined reference to `al_get_keyboard_event_source'
  9c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x86): undefined reference to `al_register_event_source'
 10c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x95): undefined reference to `al_get_display_event_source'
 11c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0xa8): undefined reference to `al_register_event_source'
 12c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0xb7): undefined reference to `al_get_timer_event_source'
 13c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0xca): undefined reference to `al_register_event_source'
 14c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0xe1): undefined reference to `al_start_timer'
 15c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0xf8): undefined reference to `al_wait_for_event'
 16c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x13e): undefined reference to `al_is_event_queue_empty'
 17c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x166): undefined reference to `al_map_rgb'
 18c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x193): undefined reference to `al_clear_to_color'
 19c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x1ba): undefined reference to `al_map_rgb'
 20c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x211): undefined reference to `al_draw_text'
 21c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x216): undefined reference to `al_flip_display'
 22c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x232): undefined reference to `al_destroy_font'
 23c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x241): undefined reference to `al_destroy_display'
 24c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x250): undefined reference to `al_destroy_timer'
 25c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccgoFaB3.o:hello.c:(.text+0x25f): undefined reference to `al_destroy_event_queue'
 26collect2.exe: error: ld returned 1 exit status

For "gcc -v -c foo.c"

#SelectExpand
 1#include <...> search starts here:
 2 c:\mingw\bin\../lib/gcc/mingw32/9.2.0/include
 3 c:\mingw\bin\../lib/gcc/mingw32/9.2.0/../../../../include
 4 c:\mingw\bin\../lib/gcc/mingw32/9.2.0/include-fixed
 5End of search list.

Here is the complete output:

#SelectExpand
  1gcc -v -c foo.c
  2Using built-in specs.
  3COLLECT_GCC=C:\MinGW\bin\gcc.exe
  4Target: mingw32
  5Configured with: ../src/gcc-9.2.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-static --enable-shared --enable-threads --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-libgomp --disable-libvtv --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --disable-build-format-warnings --prefix=/mingw --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw --with-isl=/mingw --enable-nls --with-pkgversion='MinGW.org GCC Build-20200227-1'
  6Thread model: win32
  7gcc version 9.2.0 (MinGW.org GCC Build-20200227-1) 
  8COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=i586'
  9 c:/mingw/bin/../libexec/gcc/mingw32/9.2.0/cc1.exe -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/9.2.0/ foo.c -quiet -dumpbase foo.c -mtune=generic -march=i586 -auxbase foo -version -o C:\Users\...\AppData\Local\Temp\ccAKCmgh.s
 10GNU C17 (MinGW.org GCC Build-20200227-1) version 9.2.0 (mingw32)
 11        compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP
 12
 13GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 14ignoring nonexistent directory "c:\mingw\bin\../lib/gcc/mingw32/9.2.0/../../../../mingw32/include"
 15ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/9.2.0/include"
 16ignoring nonexistent directory "/mingw/include"
 17ignoring duplicate directory "c:/mingw/lib/gcc/../../include"
 18ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/9.2.0/include-fixed"
 19ignoring nonexistent directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/9.2.0/../../../../mingw32/include"
 20ignoring nonexistent directory "/mingw/include"
 21#include "..." search starts here:
 22#include <...> search starts here:
 23 c:\mingw\bin\../lib/gcc/mingw32/9.2.0/include
 24 c:\mingw\bin\../lib/gcc/mingw32/9.2.0/../../../../include
 25 c:\mingw\bin\../lib/gcc/mingw32/9.2.0/include-fixed
 26End of search list.
 27GNU C17 (MinGW.org GCC Build-20200227-1) version 9.2.0 (mingw32)
 28        compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP
 29
 30GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 31Compiler executable checksum: 4466b5eb55ee496e209b8a8fdff6557f
 32COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=i586'
 33 c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/as.exe -v -o foo.o C:\Users\...\AppData\Local\Temp\ccAKCmgh.s
 34GNU assembler version 2.32 (mingw32) using BFD version (GNU Binutils) 2.32
 35COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/9.2.0/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/
 36LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/9.2.0/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../
 37COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=i586'

bamccaig

Member #7,536

July 2006

It looks like Allegro's main header is allegro5/allegro.h, not allegro5.h. Check to see if that is fixed in your code.

Next look at the files in C:\MinGW\lib and look for files that contain "allegro" in the name. These should correspond to your -l options, with an optional "lib" prefix, and optional version/extension suffix. E.g., liballegro5-5.0.2.dll (I haven't installed Allegro in Windows in years so I'm not sure what this is anymore).

This is really strange:

Nuxation said:

ignoring nonexistent directory "/mingw/include"

Is it possible that you have some old environment variables setup for one of your past environments? I think that path should be /c/mingw/include or perhaps /usr/include, but again I haven't used MinGW in years.

--
I mean the best with what I say. It doesn't always sound that way.

Nuxation

Member #17,744

May 2020

bamccaig said:

It looks like Allegro's main header is allegro5/allegro.h, not allegro5.h. Check to see if that is fixed in your code.

I tried with both I get same result but allegro5/allegro5.h only contain this

#include "allegro.h"

Quote:

I have "liballegro.dll.a" and "liballegro_font.dll.a" inside "C:\MinGW\lib"

Quote:

I don't know how to check that, but from my understanding :

- C:\MinGW\include is the current path where includes are on my computer (I think this is what you mean by /c/mingw/include like windows is not case sensitive on path and /usr/include do not exist)
- MinGW use itself as root "the maintainers have chosen to adopt a restricted search paradigm, which is determined on the basis of where MinGW is itself installed." (source: http://www.mingw.org/wiki/IncludePathHOWTO)

And I took care to use the one I installed this time as you can see in the at 3rd line of the full -v command "COLLECT_GCC=C:\MinGW\bin\gcc.exe"

I also deleted the old one and checked the windows PATH environement.

So I don't know where they could be and how the old env could interfere.

bamccaig

Member #7,536

July 2006

I'm a little rusty on linking with libraries in Windows using GCC. I would think that liballegro.dll.a would match -lallegro, but perhaps not. I guess you could try being more explicit: -lliballegro.dll.a and see if that helps.

If you type set into cmd.exe or dir env: into PowerShell it should output all of the environment variables. You can look through there to see if anything looks wrong (or check it for privacy concerns and share what you can).

Though looking closer it does look like C:\MinGW\include is in your searched paths here: c:\mingw\bin\../lib/gcc/mingw32/9.2.0/../../../../include

So your environment is probably fine.

I think I'm out of ideas... :-/

--
I mean the best with what I say. It doesn't always sound that way.

MikiZX

Member #17,092

June 2019

Likely Edgar will be able to help in a better way if he's around. I can only suggest how I did it - I've downloaded 'CodeBlocks' package that includes the MinGW compiler and was able to (relatively easily) setup Allegro with it - there are few tutorials about it on the web if CodeBlocks is an IDE you'd like to use.

Not sure if this helps in your case but when I compile in CodeBlocks it issues the following commands (note the command names as well as full path to the 'include' and 'lib' folders):

mingw32-gcc.exe -Wall -g -I"C:\Program Files (x86)\CodeBlocks\MinGW\include" -c C:\Users\User\Documents\Allegro\main.c -o obj\Debug\main.o
mingw32-g++.exe -L"C:\Program Files (x86)\CodeBlocks\MinGW\lib" -o bin\Debug\test.exe obj\Debug\main.o -lallegro_monolith-debug.dll

Nuxation

Member #17,744

May 2020

MikiZX said:

I can only suggest how I did it - I've downloaded 'CodeBlocks' package that includes the MinGW compiler and was able to (relatively easily) setup Allegro with it - there are few tutorials about it on the web if CodeBlocks is an IDE you'd like to use.

I wish to use g++ with a makefile to be honest. I mix my wish to make a game with my wish to learn programming. And I am trying to manage a project with makefile .

But I could consider to go back on codeblock for test or if we do not find other solution

I tried with "mingw32-gcc.exe -Wall -g -I"C:\MinGW\include" -c C:\test\hello.c -o C:\test\hello -lallegro -lallegro_font"
This compile without issue but I get a hello file which fail to be executed (Same result with gcc.exe and gcc command and without -g option)

#SelectExpand
 1Program 'hello' failed to run: No application is associated with the specified file for this operationAt line:1 char:
 2+ .\hello
 3+ ~~~~~~~.
 4At line:1 char:1
 5+ .\hello
 6+ ~~~~~~~
 7    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
 8    + FullyQualifiedErrorId : NativeCommandFailed

bamccaig

Member #7,536

July 2006

Is hello the executable or a script file? Either way, I think you want ./hello instead. I verified that at least in MSYS2 you can invoke executable binaries without a file extension so I don't think the extension matters, but if you can't figure it out otherwise you may want to try renaming it to hello.exe. Sounds like you're getting close!

--
I mean the best with what I say. It doesn't always sound that way.

Peter Hull

Member #1,136

March 2001

Nuxation said:

I hope it will not been taken badly but I tried to interpret your intention

Yes that's fine, I thought mingw did come with a unix-like shell (possibly I am getting mixed up with Cygwin)

I am wondering if we've got a 32-/64-bit mix up here. If you've got mingw32 from mingw.org that's a 32-bit compiler isn't it, but you've downloaded the allegro-x86_64-w64-mingw32-gcc-9.2.0-posix-seh-dynamic-5.2.6.0.zip which is 64-bit.

Can you check this? There is a i686 version on the releases page but I don't really understand the seh/dwarf parts of the names.

Where is Edgar when you need him?!

[edit] Confirmed the "QuickStart" works fine for me if I install allegro-i686-w64-mingw32-gcc-9.2.0-posix-dwarf-dynamic-5.2.6.0.zip from the Releases page.

Nuxation

Member #17,744

May 2020

Peter Hull said:

mingw.org said:

If you see references to "mingw32" instead of "MinGW", they are referring to the same compiler system. The project's name changed from mingw32 to MinGW is to prevent the implication that MinGW will only works on 32 bit systems (as 64 and higher bit machines become more common, MinGW will evolve to work with them).

So I should have the good version like there is mingw32 in the name. Also I think the package should work with 32 and 64 bits OS because the name start with allegro-x86_64 and x86 mean 32 bits and 64 mean 64 bits from my understanding (Source: http://net-informations.com/q/mis/x86.html)

I tried to install the dwarf version on your recommendation and ... it work ! I get the window from The wiki quickstart

Thank you very much for your help Peter and Bamccaig!

I kind of curious about the difference between the seh and dwarf version now and why they don't talk about it in the quickstart. But I guess I should check "The question has been answered to my satisfaction!" and open a new one about it.

bamccaig

Member #7,536

July 2006

Nuxation said:

Also I think the package should work with 32 and 64 bits OS because the name start with allegro-x86_64 and x86 mean 32 bits and 64 mean 64 bits from my understanding (Source: http://net-informations.com/q/mis/x86.html)

x86 means a 32-bit architecture, but x86_64 is referring to amd64, which is a 64-bit architecture that extends x86.

That said, it shouldn't matter because the Allegro package though 64-bit still was built against mingw32. This confused me at first too, but I'm guessing either mingw32 is actually 64-bit, or somehow the compiler collection is still able to build 64-bit binaries? In other words, I don't think the architecture is the problem. Also, I would hope that GCC would recognize that problem and report a better error, but I could be wrong.

--
I mean the best with what I say. It doesn't always sound that way.

Peter Hull

Member #1,136

March 2001

Glad you've solved the problem now!

Peter Hull said:

possibly I am getting mixed up with Cygwin

I was thinking of MSYS actually!

Quote:

Although (currently) offering only a 32-bit compiler suite, all of MinGW's software will execute on the 64bit Windows platforms.

There is another project called mingw-w64 which does 64 and 32 bit compilers (it was a fork from the original mingw32 in 2005 according to wikipedia)

Edgar Reynaldo

Major Reynaldo

May 2007

Late to the party I see.

I have a build guide for A5, and on the old wiki... wait... it's gone. There's now a permanent redirect to the new wiki, which is unfinished. There goes that. :/

There used to be a page for CB, MinGW-W64, and Allegro but it's gone, sadly.

I don't have many ideas, except linker order and search directories being wrong.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

Nuxation

Member #17,744

May 2020

Edgar Reynaldo said:

I don't have many ideas, except linker order and search directories being wrong.

I took the gcc command from the quickstart and the linker order seem to meet what I have seen on internet

gcc hello.c -o hello -lallegro -lallegro_font

Also it worked straight away once I have copy past the files from "allegro-i686-w64-mingw32-gcc-9.2.0-posix-dwarf-dynamic-5.2.6.0.zip" exactly as I did with "allegro-x86_64-w64-mingw32-gcc-9.2.0-posix-seh-dynamic-5.2.6.0.zip" So if it was search issue with mingw it should still be not working, no ?

Edgar Reynaldo

Major Reynaldo

May 2007

32 bit:
i686

64 bit:
x86_64

Nuxation

Member #17,744

May 2020

My computer is 64 bits (System type: 64-bit operating system, X64-based Processor) and both use mingw32 so "allegro-x86_64-w64-mingw32-gcc-9.2.0-posix-seh-dynamic-5.2.6.0.zip" should be working on my computer, no ?

Edgar Reynaldo

Major Reynaldo

May 2007

If you want to produce 64 bit binaries then use x86_64. If you want to produce 32 bit binaries use i686. That has nothing to do with what the compilers were compiled as, but what they target.

ProTip #1 : Don't put the contents of include, bin, or lib in your compiler directory. There are search directory settings for the linker and compiler that you should be using instead. This is how you get cross contamination of dlls and such.

Nuxation

Member #17,744

May 2020

Edgar Reynaldo said:

Sound wise, but this is what is recommended on the wiki quickstart, (On windows for MinGW).

At first I was planning to use this structure for my project and so add Alegro in lib folder but followed the quickstart recomandation. Like I am not comfortable with with MinGW and with Project management yet.

So you think I should go back on this first structure and find a way to add allegro file to search directory of MinGW ?

bamccaig

Member #7,536

July 2006

It's perfectly fine to install the Allegro files into your compiler directories. Especially if game programming with Allegro is the only thing you're using MinGW for. It's easier than configuring a separate environment, and it's harmless for most users to do it this way. It can be argued that it's semantically a "bad practice", but I think you'd only run into issues if you started installing additional libraries with conflicting dependencies. You can worry about changing that once you get the basics/fundamentals down. It's better to do things the easy way and make progress than it is to get blocked trying to figure out the harder, correct way. If you've got a working environment then move on and start programming!

--
I mean the best with what I say. It doesn't always sound that way.

Edgar Reynaldo

Major Reynaldo

May 2007

Do it right or you will forever be mediocre. Learn good habits now, before you get too lazy to learn new ones. Otherwise, be prepared for odd programming bugs appearing that you never had before because you mixed your dlls or headers.

:-X

bamccaig

Member #7,536

July 2006

Doing it right would be installing a Linux distro. :-*

--
I mean the best with what I say. It doesn't always sound that way.

Edgar Reynaldo

Major Reynaldo

May 2007

Windows may suck. But Linux sucks too. Keep trying. :-*