On Wed, 6 Oct 2010 19:27:57 +0200 Loïc Minier <loic.min...@linaro.org> wrote:
> On Wed, Oct 06, 2010, Neil Williams wrote: > > No. pkg-config specifies architecture-independent metadata which is > > static within any single source release, not architecture-dependent > > variables deduced at build time. > > it's not architecture independent at all (which is why it's mostly in > /usr/lib/pkgconfig rather than /usr/share/pkgconfig) The data in a .pc file is used to generate the data needed for the build, it does not circumvent the generation of this data. Also, pkg-config itself understands how to ensure that this data is available in a way which understands cross-building. > The list of libraries might differ, or some random var, or simply the > version of the file, options or anything. .pc files don't contain metadata like -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS and the like. That goes in files like config.h and is *generated* during the build from tests on the actual system because different systems of the same architecture will change the results of the calculations. It is wrong to rely on that data being included in any part of the -dev package, stuff like endianness and the size of char needs to be generated / calculated / retrieved from a standard location. Not included into the -dev package. That is *system-dependent* data as well as architecture-dependent and it has no place in a -cross -dev package. dpkg-cross has a mechanism for retrieving only those pieces of metadata which cannot be calculated without compiling and then executing a test program. This mechanism itself is sub-optimal and prone to breakage - it will not bear extending to data which *can* (and therefore should) be calculated within each build environment or where merely compiling a test program will suffice to retrieve the meta data (e.g. whether a particular library function exists). Shortcuts are no good for anyone. Ubuntu has already patched dpkg-cross to extend what shortcuts are already available into territory which is not supportable in Debian. -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 Embedding that in a -dev package is just wrong. It needs to be calculated according to the libc config in the environment. That is not architecture-dependent, that is system dependent - e.g. uClibc does not necessarily include all of the struct_tm data. > First, there is a difference between what the architecture needs, and > what tcl was built with. So the cross build should calculate what the architecture needs, not what is retained from the build environment of the dependency. Data from the build environment of tcl has nothing to do with the data which needs to be calculated from the build environment of the package using tcl. Tcl is built on machine foo - the calculations made in that build have nothing to do with the data needed by the build on machine bar. All pkg-config lists are the library names, not the definitions of what size structs are and the rest. -DTCL_CFGVAL_ENCODING=\"iso8859-1\" -DMODULE_SCOPE=extern\ __attribute__ \(\(__visibility__\(\"hidden\"\)\)\) -DTCL_SHLIB_EXT=\".so\" -DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1 -DHAVE_GETPWNAM_R=1 That stuff needs to be tested against the build environment, not assumed to be present. Quite apart from the rest, relying on scripts like this prevents bootstrapping of new architectures. The build system should calculate and determine these pieces of data, not inherit them from some other random system which may or may not have the same configuration. > In some cases, it might actually be > important that you use the same values as tcl did. If those values do not actually match the build or runtime environment of the package, you're welcome to triage the resulting bugs. I won't be a party to that particular mess. > But I think it's > not the case here; I rather see this as some non-autoconf approach to > spreading the right build settings. Cross-building has never supported build systems other than autoconf particularly well. Nothing dpkg-cross can do about that - outside the scope of the script. > > The machine preparing the -dev package does not necessarily have the > > same configuration as the target device of the cross-build - these > > things need to be *calculated* not retrieved from some previous > > build somewhere else. > > You're saying just the same thing again; it might be entirely valid > to use the exact same values as the ones which were used for the tcl > build; It usually is not and removing the ability to determine this is not helpful. "might be" is not adequate. It is either always valid or it needs to be calculated. > I don't think it's the case here though. I think tcl is > trying to provide non-autoconf apps with a way to get the right > config. It is wrong to have that data in the -dev package and rely upon it in a different build. There is no safe way of dpkg-cross supporting such mangling - it does quite enough of that itself without adding special cases like this. There are other packages "trying to provide non-autoconf apps with a way to get the config" but none has so far come up with a *standard* or even *generalised* way of doing that. Do you think I'm rejecting this idea just to be awkward? No, it's because what you request is horrendously fragile, unpredictable and more likely to break builds than to assist builds. There is no safe way for dpkg-cross to mangle these files or to determine precisely which of these non-standard scripts can be parsed and which cannot. Special cases do not help - dpkg-cross already has too many of those. I'll document the behaviour but dpkg-cross cannot withstand yet more special cases and still be usable for the existing packages which it has to support. Every interpreted language, every GObject marshaller and every ORM package is going to want specialised support and there is simply no reliable way of implementing a bespoke solution for each one. None of the upstream teams, nor most of the Debian maintainers, care sufficiently about cross-building to maintain such package-specific support. Not every package in Debian is ever going to be compatible with cross-building and dpkg-cross cannot support everything. (I doubt that Multiarch will be able to support things like this either - there will always be exceptions.) Cross building already has sufficient special-cases and exceptions - adding more does not help anyone, least of all those who actually have to fix either the cross builds or the cross-building tools. It is not safe to leave files in the package nor is it safe to move files into arbitrary locations when there is no reliable and standardised way to determine the usefulness of a particular kind of file. Package specific config scripts cannot be supported and even build-system specific ones are not necessarily going to work without a lot of ongoing maintenance. Patch the original package to understand cross-building and how to calculate the necessary meta data. If there is data which cannot be calculated without executing a foreign architecture binary, then dpkg-cross should be able to help and I'll look at how that can be done but the rest of the data needs to be generated from within the cross-building environment. Anything else just isn't sufficiently robust or supportable. Why cross-build tcl in the first place? What functionality is meant to be changed or removed? Cross-building packages to end up with a binary which is almost identical to the natively built package is a waste of time. Seeking to be able to cross-build every package in Debian is a pointless exercise and far beyond the scope of what dpkg-cross can support. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgph4a5ay1W1R.pgp
Description: PGP signature
