On Sun, Jul 10, 2011 at 8:18 AM, Bastiaan Timmer <[email protected]>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.
