[Libcdio-devel] MinGW support satus

[Pete Batard]

After a little bit of fumbling around, I think I'm pretty much exactly 
where I want to be with MinGW support, at commit c81c4388...

I tested Linux (x86_32, x86_64 & ARM), cygwin and MinGW (32 & w64) and 
the results looked good, so next stop now will be MSVC.

But first, let me give a breakdown of the commits that happened in the 
-pbatard repo:

1. Because I originally thought the simplest course of action would be 
to override off_t for MinGW LFS (defined in sys/types.h) in 
cdio/types.h, and cdio/types.h includes sys/types.h, there was an 
overhaul of the headers, primarily aimed at removing sys/types.h in 
favour of cdio/types.h. While I was at it, I fixed the various missing 
HAVE_### that I saw (but I tried to leave platform specific files alone) 
and other minor issues => Improve headers parts 1-4

2. Because some MinGW32 headers like stdio.h include <sys/types.h>, the 
option of overriding off_t in cdio/types.h was not exactly the best 
choice, so I added a complete sys/types.h, that redefined off_t to 64 
bit, and set its location (include/override) to be looked up first by 
MinGW => MinGW LFS: add <sys/types.h> override for 64 bit off_t

3. After that, what was needed was to prefer the 64 bit version of calls 
such as fseeko64 (which MinGW has, but not fseeko), lseek64, etc.
Now, this is the part that is probably the most heavy handed, as:
- we also need to fix the stream stat() for 64 bit, as it returned a 
ssize_t, which means on 32 bit platforms, you would never be able to get 
values beyond 2 GB. Because the libcdio implementation of stat() differs 
from the POSIX prototypes (it doesn't take a stat arg), I just switched 
to using an off_t there
- While I was at it, I also fixed read() and seek() to match their POSIX 
counterparts, as the code states this as our goal. I took a liberty with 
calls that are supposed to use a f_pos and used off_t as a replacement 
there again.
The two changes above are likely to be the most visible to our users, 
and resulted in modifications to code that use streams => cdrdao, bincue 
and nrg. I Broke the commit in 2 parts as a result. The image related 
code should now have LFS as a result (through NRG support seems to have 
to cast some length values to 32 bit, so it may still be limited).

4. I then moved on to MinGW-w64 where all hell broke loose, as I quickly 
found out that off_t can be defined in at least 4 headers, not just 
sys/type.h, therefore we'd have to override more than sys/types.h.
The main reason I wanted to go a header override is that it would 
benefit us for MSVC (as the sys/types.h there is pretty useless, and 
also defines off_t to long always), but it became pretty clear that it 
had too many additional drawbacks, such as an increased likelihood of 
conflicts, the requirement for a header that would work on 3 platforms 
(MinGW32 + MinGW-w64, that are pretty different, and MSVC), and a major 
headache for libcdio users who would want LFS support and include the 
code in their application, as they would have to follow suit.
The better alternative then is to define off_t as a gcc macro, along 
with its guards, so that our 64 bit version would be used regardless.
This is what is done in "MinGW LFS: override off_t only rather than 
sys/types.h". This commit also adds the detection of the 64 bit 
alternatives we need to use for LFS in MinGW, such as _stati64, lseek64.
A similar technique should be usable for MSVC, and is probably our best 
option, short of using a CDIO_OFF_T everywhere we use off_t, that would 
be defined to either 32 or 64 bit

5. Since the removal of sys/types.h references was no longer needed, 
these were restored in "Improve headers - part 5", which hopefully 
should ensure that other platforms see minimal change.

6. The rest of the commits are mostly warning fixes and beautification 
of the build process. The one warning I'm not suere how to address is 
the "operation on '*b_erasable' may be undefined" in mmc_hl_cmds.c. Else 
I tried to fix the ones I got (expect from cygwin, where there are also 
a bunch of "warning: array subscript has type 'char'" which don't bother 
me too much).

Unless requested, I'm not planning to e-mail copies of all these commits 
to the mailing list, as these can easily be browsed from [1].

Regards,

/Pete

[1] 
http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=shortlog;h=refs/heads/pbatard