|
|
|
| Allegro 4.1.18 WIP |
|
ReyBrujo
Moderator
January 2001
 |
Quote: echo #define ALLEGRO_GENERATED_BY_MAKEFILE_TST > obj\mingw32\asmcapa.h Maybe it is executing it from the wrong path? (OT: By the way, just noticed 7-Zip shows the original user and group in the tar.gz file -- |
|
gnolam
Member #2,030
March 2002
 |
Quote: Does the obj/mingw32 directory actually exist (it should)?
Yep... But is it really supposed to go in obj/mingw32 and not obj/mingw32/alleg or something like that? -- |
|
A J
Member #3,025
December 2002
 |
i added CPU_IA64 CPU_SSE3 CPU_AMD64 detection. ___________________________ |
|
ReyBrujo
Moderator
January 2001
|
Quote: But is it really supposed to go in obj/mingw32 and not obj/mingw32/alleg or something like that? Yes, it goes in obj/mingw32, because no matter if you are building the release, profiling or debug libraries, the detection is always the same. Go to allegro directory, and type echo #define ALLEGRO_GENERATED_BY_MAKEFILE_TST > obj\mingw32\asmcapa.h -- |
|
gnolam
Member #2,030
March 2002
|
Quote: Go to allegro directory, and type echo #define ALLEGRO_GENERATED_BY_MAKEFILE_TST > obj\mingw32\asmcapa.h
Yep, works if I do it by hand... After that it can continue to compile past that part, only to choke and die a bit later: gcc -Wall -Wno-unused -I. -I./include -x assembler-with-cpp -o obj/mingw32/alleg /asmlock.o -c src/win/asmlock.s windres --include-dir include -O coff -o obj/mingw32/alleg/dllver.o -i src/win/d llver.rc gcc: src/win/dllver.rc: No such file or directory gcc: warning: `-x c' after last input file has no effect gcc: no input files windres: no resources make: *** [obj/mingw32/alleg/dllver.o] Error 1
-- |
|
Evert
Member #794
November 2000
 |
Does that file exist? (Again, it should... it does in my local installation at any rate, which may not say much as that's a UNIX installation, but still... the contents of the archive should be the same). |
|
Mika Halttunen
Member #760
November 2000
 |
|
Daniel Schlyder
Member #257
April 2000
 |
Not that it helps you, but the Zip archive compiled cleanly for me using MinGW GCC 3.4.2. I have downloaded the individual MinGW packages though, not the installer, but I don't see why that would matter. Maybe your uncompressor messed up the Allegro archive? |
|
gnolam
Member #2,030
March 2002
|
Quote: Does that file exist? (Again, it should... it does in my local installation at any rate, which may not say much as that's a UNIX installation, but still... the contents of the archive should be the same).
And again, it does. [EDIT] -- |
|
Daniel Schlyder
Member #257
April 2000
|
Quote: Found the problem. I have "cd c:\" in my autorun for the Windows console. "autorun"? You mean shortcut? If so, you can set 'Start in' under Properties -> Shortcut to "c:\" instead. |
|
ReyBrujo
Moderator
January 2001
|
Ugh, yes, makes seems to spawn a new command, which cd's back. Remove that autocommand and try make clean and build again from scratch. And turn off the antivirus for the windres problem. Might help. -- |
|
gnolam
Member #2,030
March 2002
|
No, I mean in my autorun. HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Command Processor->Autorun The "start in" property of shortcuts only apply to (no surprise here) shortcuts, so when starting the console manually you'll still end up in c:\blah\foo\bar\annoyinglylongpath\somewhereyoudon'twanttobe\ ... unless you add a CD command to the console autorun. -- |
|
Daniel Schlyder
Member #257
April 2000
|
Aha, ok, cool. |
|
lucaz
Member #4,194
January 2004
|
The manual isn't in tatula.demon, when it will be updated? |
|
Oscar Giner
Member #2,207
April 2002
 |
I just installed SUSE 9.2 64 bit version and decided to give Allegro 4.1.18 a try. The library compiles fine, but it fails when compiling the demo: gcc -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro -DALLEGRO_USE_C -DALLEGRO_LIB_BUILD -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused -c ./demo/demo.c -o obj/unix/demo.o gcc -s -Wl,--export-dynamic -o demo/demo obj/unix/demo.o -Llib/unix -lalleg-4.1.18 -lalleg_unsharable -lm lib/unix/liballeg-4.1.18.so: undefined reference to `_colorconv_rgb_scale_5x35' lib/unix/liballeg-4.1.18.so: undefined reference to `_colorconv_indexed_palette' lib/unix/liballeg-4.1.18.so: undefined reference to `_colorconv_rgb_map' collect2: ld devolvió el estado de salida 1 make: *** [demo/demo] Error 1
[edit] -- |
|
tobing
Member #5,213
November 2004
 |
So now I've updated and compiled everything on MSVC7.1, and here is the new vcproj-file with the new files included. Edit: Urgs. Something seems to be missing, I'll correct that... Edit: Evert, I can't find the implementation of the functions gui_get_screen() and gui_set_screen(), where are they supposed to be? It's strange, I could build everything from the makefiles, but using the workspace these symbols are missing, and using text search I can't find them. |
|
Evert
Member #794
November 2000
|
Quote: I just installed SUSE 9.2 64 bit version and decided to give Allegro 4.1.18 a try. The library compiles fine, but it fails when compiling the demo: That's odd... it's indeed possible that it's a problem with the C version of the library. Peter is working on (has) a patch that makes Allegro work better on 64 bit CPUs, but it hasn't been applied yet. You may want to check with him if he's aware of possible problems. Quote: and here is the new vcproj-file with the new files included.
Uhm... where? Quote: I can't find the implementation of the functions gui_get_screen() and gui_set_screen(), where are they supposed to be? Lines 960 and 970 from src/gui.c. |
|
Peter Wang
Member #23
April 2000
|
Quote: That's odd... it's indeed possible that it's a problem with the C version of the library. Peter is working on (has) a patch that makes Allegro work better on 64 bit CPUs, but it hasn't been applied yet. You may want to check with him if he's aware of possible problems. There are no known problems with the patch, but some threading problems seem to show up more on AMD64 than x86 (or at least, on a gentoo box vs a slackware box). The patch itself should be applied fairly soon. I don't know why you're getting undefined references to the colorconv stuff though. Try make depend first. BTW, make forking itself over and over is the normal way make operates.
|
|
tobing
Member #5,213
November 2004
|
Something has gone wrong, my local gui.c was not properly copied or something. Now it works and builds fine, so here's the vcproj-file. |
|
Oscar Giner
Member #2,207
April 2002
|
Quote: I don't know why you're getting undefined references to the colorconv stuff though. Try make depend first.
That didn't work [edit] [edit 2] -- |
|
Kirr
Member #5,060
September 2004
 |
Perhaps all Allegro docs/build/* docs should begin with a big big warning that you should delete all previous Allegro versions completely, including a search for alleg through all your hard drive. About half of "Allegro doesn't work" problems result from the previous version pieces remaining here and there. -- |
|
Oscar Giner
Member #2,207
April 2002
|
I installed it on a clean linux. There weren't old allegro versions anywhere (SUSE, at least the 64 bit version, doesn't include allegro). -- |
|
A J
Member #3,025
December 2002
|
tobing, can you please provide some more info to allow this project file to be used properly. a directory listing, showing the file tree required.. as currently the project file alone does not help you figure out where to put everything. also some notes about the environment you used to make this project file. apologies if all this info is in the above posts, i am requesting that you organize it into a single package. can you also tell me if you still have to go to the command line to generate the asm files? ___________________________ |
|
tobing
Member #5,213
November 2004
|
Sorry, I missed out the details. The project file has to be put into the allegro directory, top level (where the makefiles are). Nothing else is required. To use the project file, first build for MSVC using the makefile. After that the project file can be included in any solution and used to rebuild the allegro library. All output files are put where the usual make also puts them, but the solution file automatically adds the output libraries to the linker statement, so it's not necessary to add the allegro libraries to the game project in the linker options. Would this be sufficient? If not, please let me know... |
|
A J
Member #3,025
December 2002
|
thank you, it is most helpful. i thing leaves me wondering. what was the purpose of having a msvc project for allegro ? ___________________________ |
|
|
|
)
I tried with make depend and then make clean. Allegro 1.1.17 works, though.
I don't know why it didn't work the first time