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.
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.
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?
]]>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)
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:
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
/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.
]]>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"}
// 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
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 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++
For "gcc -v -c foo.c"
Here is the complete output:
]]>
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:
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.
]]>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"
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 have "liballegro.dll.a" and "liballegro_font.dll.a" inside "C:\MinGW\lib"
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 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.
]]>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...
]]>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
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)
]]>
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 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.
]]>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.
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.
]]>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.
]]>Glad you've solved the problem now!
possibly I am getting mixed up with Cygwin
I was thinking of MSYS actually!
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)
]]>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.
]]>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 ?
]]>32 bit:
i686
64 bit:
x86_64
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 ?
]]>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.
]]>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.
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 ?
]]>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!
]]>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.
]]>
Doing it right would be installing a Linux distro.
]]>Windows may suck. But Linux sucks too. Keep trying.
]]>Linux only sucks when it's installed in a vacuum cleaner.
]]>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 !
]]>Linux only sucks when it's installed in a vacuum cleaner.
https://www.kaspersky.com/blog/xiaomi-mi-robot-hacked/20632/
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.
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
]]>