reassign 505047 qmmp thanks Zed Pobre wrote: > The API requests to know which files you have available on the system, > and you tell it by setting an appropriate define. If you fail to set > that define when you have the file, you've lied to the API. > Libmodplug is behaving exactly as you told it: it's not including the > files where it would normally pick up C99 typedef instructions, > because it's been told that it is in an environment where none of > those headers exist, and the C99 defines are handled elsewhere. I finally understood your position. Hurray.
>>>> 1st part: advance .pc file to include -DHAVE_STDINT_H in CFLAGS >>> No! This is wrong! You cannot force HAVE_STDINT_H without testing >>> for it first, or it will break on systems that don't actually have >>> stdint.h! >> Debian systems (gcc) should on all arches. > > You're missing the point: upstream is making sure that libmodplug will > build on systems that aren't Debian. I am unwilling to break from the > API that enables this without compelling reason. You may easily apply Debian-specific patch to Debian build system of libmodplug-dev, though. >>> No! This is what I was trying to tell you was wrong! This won't >>> include stdint.h if inttypes.h exists, and that will break under >>> Debian, which provides both. >> %(. Why should libmodplug require both and what will be broken? > > Libmodplug requires the C99 types come from *somewhere*. It doesn't > know where. It knows they might be in stdint.h or in inttypes.h or in > some other location that the build environment is including > automatically for it. It has no way of knowing which file contains > the typedefs it needs, but it knows that two files commonly have them > and there's no harm in including one that isn't needed, so it will > attempt to include both. Unfortunately, a simple #include on the file > will break on systems where the file not only doesn't contain the C99 > typedefs, but doesn't exist at all, so libmodplug asks the build > environment first if the file exists, and then only includes it if the > build environment tells it yes. It does this for both files. > > If you change the code so that it only includes the first one found, > but the build environment has both files and the typedefs are in the > second (and this is the case under Debian), it will include the first > file, which doesn't have the typedefs, fail to include the second even > though it exists, and then die messily when it attempts to create its > abstraction layer because it doesn't have a functioning C99 > environment. > > If you wish to avoid breakage, you MUST include both files if they > exist, and you MUST check to see if they exist before you include > them. There's no way around this unless you go to an OS check instead > of a file check, and that's an even uglier can of worms, since you > have to maintain a map of exactly which OS uses which file for every > possible OS, and then you *still* have to query the build environment > about it and set the right define, so it doesn't actually save you any > work. > > The correct thing is for the including package to test which files > exist and set the correct define, or if the including package doesn't > care if it builds outside of Debian, it can just set -DHAVE_STDINT_H > and -DHAVE_INTTYPES_H on its own blindly, assuming that libc6-dev will > provide them. It seems that you are right. I must apologize to you and I am doing this. -- Eugene V. Lyubimkin aka JackYF Ukrainian C++ developer, Debian APT contributor
signature.asc
Description: OpenPGP digital signature
