[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-devel] MinGW support satus

From: Pete Batard
Subject: [Libcdio-devel] MinGW support satus
Date: Thu, 26 Jan 2012 21:14:07 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]