Re: [Libcdio-devel] [Libcdio-help] Large file support and binary compatibility on 32 bit systems

[Rocky Bernstein]

On Sun, Jul 10, 2011 at 8:18 AM, Bastiaan Timmer <address@hidden>wrote:

>
> The change to use int32_t instead of off_t is now in git. Let's see if that
> solves the problem you were experiencing.
>
>   Ok, tested it and it works.
>

Good to hear.  It would be neat if it were possible to create a small test
case of your code that fails with the last release but succeeds with what is
in git.
That way, I could add it to the list of tests that get run. Of course, this
test would only be run when if a CD-DA disk is detected in a drive, but
there are already other tests that work that way in there now. So the
mechanism for skipping tests is already in place.



> Of course, the full config file also solved it, so I also applied this
> change to the 0.82 release and it works there as well (without the full
> config or manually adjusting _FILE_OFFSET_BITS). Considering this, and:
>
>  It is not something I want to undertake. But if someone else is
> interested in doing this, I welcome patches.
>
> Maybe you should consider reverting that change (until it is done without
> the global symbols)? Unless you suspect there are more problems that are
> solved by the full config, which are not solved by the off_t -> int32_t
> change.
>

cdio_config.h was originally created so some of the other C Preprocessor
defines toward the top of the file should be consulted.

Previously it had been a little bit more hacky to chop off the end of that
file after some number of lines. And it was maintenance problem as I had to
change the truncate limit several times.. So I think it better to include
the whole config.h and have it triggered by "make" rather than
"configure".

Also, as you suggest, there may be other places where off_t should be
int32_t.

That said, the change does now cause warnings in compiling some of the
example files;  The warning is that some C preprocessor symbols have already
been defined. So down the line my thought is to either fix those example
programs by undef'ing before #including cdio_config.h or reverting the
change. I don't know which I will do yet.

If folks have thought or comments, I'd be interested.


> I suppose you would want the config.h file generated by autoconf to have
> the new symbol names in it, and it is not good enough to just use 'sed'
> after it is generated to rename the symbols?
>

The libcdio source could might have to change in some places to use the CDIO
namespace preprocessor symbols rather than the original config.h ones. And
it is possible that some symbols in config.h are there for standard C
library routines that get called.

But I don't consider renaming all symbols needs to be done 100%. Even if
renaming only some of them to the CDIO namespace can be done, that is still
probably an improvement.


I might be able to do the latter for you, but I've never worked with
> autoconf or the GNU build system at all, so I'm sorry to say I probably
> can't help with that either (though I'm willing to give it a go).
>

My experience has been that it is more important to have people who are
willing to help than have people who know a lot. If everyone took a point of
view that "since I never used X, I can't be of any help,"  then there would
be no software written with it at all . I knew absolutely nothing about CD's
before I started extracting bits from vcidmager and cd paranoia which formed
this library.


>
> Anyway, thanks again for the quick fix(es), I am really loving this
> library!
>
>
Good to hear. Share and enjoy.