package libmodplug-dev tags 505047 +patch thanks Zed Pobre wrote: > On Tue, Nov 11, 2008 at 07:31:30PM +0200, Eugene V. Lyubimkin wrote: >> Ok, then libmodplug should do "#if defined(<one>) #elif defined(<two>) #else >> #error intXYZ_t types are unavailable #endif" rather than generate errors in >> applications linked to libmodplug. This is a correct approach, and approach >> which I currently see in libmodplug's stdafx.h is wrong and needs fixing. You >> can't rely on intXYZ_t types without checking that at least one of >> <inttypes.h> or <stdint.h> headers are included (see above example of check). > > Let me get this straight -- you want to include a bunch of extra code > to determine whether or not the known-size types have been included, Well, if header _unconditionally_ do typedefs with intXYZ_t, yes, you should. No? Or remove that typedefs, or move them to some #ifdef too.
> and abort at compile-time if they are not, inside a file that will > already cause an abort at compile-time if they are not, and then add a > false error message about types not being available, even if they are > and simply weren't included because the proper defines weren't set? I > can't even follow your reasoning on this one, since doing this won't > remotely help your code compile. $ pkg-config --cflags libmodplug -I/usr/include/libmodplug Should I compile libastral.so to determine what additional defines I should provide to libmodplug headers? > Also, can you provide an example of a run-time (as opposed to > compile-time, and thus pre-link) error caused by this? So far, I > haven't been made aware of any -- the only issue that has been brought > to my attention is a compile-time issue with a file not being included > -- and that compile-time issue is not inside of modplug, but inside of > another package failing to use the modplug header correctly (i.e. with > the correct defines in place to say which headers should be included > by stdafx.h). Are you joking? libmodplug's stdafx.h does unchecked typedefs, and qmmp is culprit? >> This is unrelated to this bug and thus off-topic on this bug thread, but I >> can >> say that 'LPVOID' and company are Windows API crap under Linux code base of >> libmodplug and I don't see a reason why a Linux code should even see such >> types. But it's my own IMHO and wish. > > You are aware that libmodplug is not only also used in MS Windows > softare, but that the original development was from the MS Windows > application Modplug, right? Well, I understand reasons. It's only my wish that Linux port of libmodplug to get rid of Windows-related stuff. > Incidentally, I see you're playing ping pong with the bug assignment, You too. > and that's fine, but be aware that since you won't let me reassign the > bug, my solution is going to be to tag it wontfix and close it unless > you can demonstrate either widespread support for breaking upstream > compatibility with other environments, or a patch that solves your > problem without doing so. Ok, here is the patch: 1st part: advance .pc file to include -DHAVE_STDINT_H in CFLAGS 2nd part: --- /usr/include/libmodplug/stdafx.h 2008-09-24 20:55:12.000000000 +0300 +++ stdafx.h 2008-11-11 22:27:14.455164345 +0200 @@ -29,9 +29,10 @@ #endif #ifdef HAVE_INTTYPES_H # include <inttypes.h> -#endif -#ifdef HAVE_STDINT_H +#elif defined(HAVE_STDINT_H) # include <stdint.h> +#else +# error "You should define HAVE_INTTYPES_H or HAVE_STDINT_H" #endif #include <stdlib.h> #include <stdio.h> -- Eugene V. Lyubimkin aka JackYF Ukrainian C++ developer, Debian APT contributor
signature.asc
Description: OpenPGP digital signature
