Mingw do not find Allegro lib

no-reply@allegro.cc (Nuxation) — Wed, 27 May 2020 11:52:23 +0000

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.

no-reply@allegro.cc (Peter Hull) — Wed, 27 May 2020 19:17:33 +0000

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?

no-reply@allegro.cc (Nuxation) — Wed, 27 May 2020 20:06:22 +0000

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

no-reply@allegro.cc (bamccaig) — Wed, 27 May 2020 21:21:19 +0000

/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 

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.

no-reply@allegro.cc (Nuxation) — Wed, 27 May 2020 22:08:52 +0000

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

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'

no-reply@allegro.cc (bamccaig) — Thu, 28 May 2020 01:24:38 +0000

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.

no-reply@allegro.cc (Nuxation) — Thu, 28 May 2020 02:11:36 +0000

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.

no-reply@allegro.cc (bamccaig) — Thu, 28 May 2020 02:43:00 +0000

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...

no-reply@allegro.cc (MikiZX) — Thu, 28 May 2020 04:44:35 +0000

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

no-reply@allegro.cc (Nuxation) — Thu, 28 May 2020 12:07:53 +0000

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

no-reply@allegro.cc (bamccaig) — Thu, 28 May 2020 18:22:06 +0000

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!

no-reply@allegro.cc (Peter Hull) — Thu, 28 May 2020 18:27:32 +0000

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.

no-reply@allegro.cc (Nuxation) — Thu, 28 May 2020 19:10:16 +0000

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.

no-reply@allegro.cc (bamccaig) — Thu, 28 May 2020 19:52:58 +0000

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.

no-reply@allegro.cc (Peter Hull) — Thu, 28 May 2020 20:54:43 +0000

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)

no-reply@allegro.cc (Edgar Reynaldo) — Thu, 28 May 2020 23:44:09 +0000

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.

no-reply@allegro.cc (Nuxation) — Sun, 31 May 2020 12:50:04 +0000

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 ?

no-reply@allegro.cc (Edgar Reynaldo) — Mon, 01 Jun 2020 06:17:38 +0000

32 bit:
i686

64 bit:
x86_64

no-reply@allegro.cc (Nuxation) — Mon, 01 Jun 2020 09:58:06 +0000

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 ?

no-reply@allegro.cc (Edgar Reynaldo) — Mon, 01 Jun 2020 14:17:44 +0000

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.

no-reply@allegro.cc (Nuxation) — Mon, 01 Jun 2020 17:41:26 +0000

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 ?

no-reply@allegro.cc (bamccaig) — Mon, 01 Jun 2020 19:07:17 +0000

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!

no-reply@allegro.cc (Edgar Reynaldo) — Fri, 05 Jun 2020 02:55:58 +0000

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.

no-reply@allegro.cc (bamccaig) — Fri, 05 Jun 2020 06:45:11 +0000

Doing it right would be installing a Linux distro.

no-reply@allegro.cc (Edgar Reynaldo) — Sat, 06 Jun 2020 00:05:19 +0000

Windows may suck. But Linux sucks too. Keep trying.

no-reply@allegro.cc (bamccaig) — Sat, 06 Jun 2020 00:27:54 +0000

Linux only sucks when it's installed in a vacuum cleaner.

no-reply@allegro.cc (Nuxation) — Sun, 07 Jun 2020 01:20:02 +0000

Ok I will follow both of your advice, I will keep like this until I finish the "Allegro-Vivace guide" then I will re-install MinGW and use allegro in the lib folder.

PS: I use Windows and Linux, they both sucks !

no-reply@allegro.cc (Arthur Kalliokoski) — Tue, 09 Jun 2020 05:23:50 +0000

bamccaig said:

Linux only sucks when it's installed in a vacuum cleaner.

https://www.kaspersky.com/blog/xiaomi-mi-robot-hacked/20632/

Quote:

Examining the firmware, Giese and Wegemer learned a couple of interesting things about Xiaomi smart devices. First, the Mi Robot firmware is basically Ubuntu Linux, which is regularly and quickly patched. Second, it uses a different superuser password for each device; there’s no master password that could be used to mass-hack a whole lot of vacuum cleaners at once. And third, the system runs a firewall that blocks all ports that could be used by hackers. Again, hats off to Xiaomi: By IoT standards, this is surprisingly good protection.

The researchers also learned something disappointing about Mi Robot, however. The device collects and uploads to Xiaomi cloud a lot of data — several megabytes per day. Along with reasonable things such as device operation telemetry, this data includes the names and passwords of the Wi-Fi networks the device connects to, and the maps of rooms it makes with its built-in lidar sensor. Even more disturbing, this data stays in the system forever, even after a factory reset. So if someone buys a used Xiaomi vacuum cleaner on eBay and roots it, they can easily obtain all of that information.

no-reply@allegro.cc (Edgar Reynaldo) — Wed, 10 Jun 2020 18:45:51 +0000

AK said:

So if someone buys a used Xiaomi vacuum cleaner on eBay and roots it, they can easily obtain all of that information.

A11 UR VaCuUms bEloNg 2 U5