Re: [AD] microscopic issues compiling 4.1.13 with latest MinGW packages

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> Compiling 4.1.13 with latest MinGW (candidate/release packages, gcc 3.3.3)
> I get several warnings as follows:
>
> src/win/wddraw.c: In function `init_directx':
> src/win/wddraw.c:52: warning: dereferencing type-punned pointer will break
> strict-aliasing rules src/win/wddwin.c: In function
> `update_matching_window':
> src/win/wddwin.c:231: warning: dereferencing type-punned pointer will
> break strict-aliasing rules [snipped about 30 more]
>
> Are they harmless? I think they're from the profiling and debug builds and
> not release build, but I don't remember the syntax to output stdout and
> stderr to the same file, so I haven't confirmed this.

Yes, they are harmless.  They occur with arguments passed to a function with 
a slightly different type than their original type (e.g. cast to LPVOID or 
cast to a base structure).  You can shut them up by going through the 
appropriate temporary, which will be eliminated by the optimizer.

I'll fix them before the next release if nobody steps up to do it.

> Also, I redirected all stderr output to a file and noticed the following
> lines among the above mentioned error messages:
>
> ar: creating lib/mingw32/liballeg_s.a
> ar: creating lib/mingw32/liballd_s.a
> ar: creating lib/mingw32/liballp_s.a
> ar: creating lib/mingw32/libaldat.a
>
> Shouldn't these go to stdout? I guess it's probably the tool and not
> Allegro's build system that controls this, though, but thought I'd mention
> it just in case.

Unix rule #1: be quiet on success.

> Also, also, I get the following error when running "make installall". All
> files seem to have been copied correctly, though. At least, I can link
> successfully with my game. (Error is in the last four lines, just
> including the rest for context.).
>
> [snipped copying of a lot of files]
> E:\bin\mingw\include\allegro\inline\system.inl
>         1 file(s) copied.
> The optimised statically linked MinGW32 library has been installed.
> make[1]: Leaving directory `E:/libs/allegro-4.1.13'
> make msg lib install DEBUGMODE=1
> make[1]: Entering directory `E:/libs/allegro-4.1.13'
> Compiling Allegro for MinGW32, debugging statically linked. Please wait...
> make[1]: Nothing to be done for `lib'.
> copy lib\mingw32\liballd_s.a E:\bin\mingw\lib
>         1 file(s) copied.
> copy include\winalleg.h E:\bin\mingw\include\winalleg.h
>         1 file(s) copied.
> md E:\bin\mingw\include\allegro\platform
> A subdirectory or file E:\bin\mingw\include\allegro\platform already
> exists. make[1]: *** [E:/bin/mingw/include/allegro/platform] Error 1
> make[1]: Leaving directory `E:/libs/allegro-4.1.13'
> make: *** [installall] Error 2

Aaargh! :-)  This is the same error as on MacOS X: the makefile rules are 
written so that the directory should not be created if it already exists.  
That seems to be very fragile though, so we will probably need to resort to 
the MacOS X approach everywhere.

-- 
Eric Botcazou