Bug#244897: Broken Debian httpd/APR packaging
On Thu, Aug 19, 2004 at 05:34:53PM +1000, Adam Conrad wrote:
> Joe Orton wrote:
> >
> > And the libstdc++.so soname changes when the C++ ABI changes. Not sure
> > how this is relevant.
>
> But the SONAME of libfoo that depends on libstdc++ doesn't change. Same
> goes for compiling a library against any new version of a depending lib.
> Since libtool no longer forces transitive dependencies, there's no way
> for a top-level binary to see that the ABI has changed.
All C++ libraries and programs have a dependency on libstdc++.so, the
soname for which is defined by GCC upstream and versioned according to
ABI changes. If I compile a C++ program or library on a Red Hat or SuSE
system it will either work or fail to run from unresolved libraries on a
Debian system according to whether the same C++ ABI is supported.
So I don't see how the C++ example is relevant. If I compile an APR 0.9
program or httpd 2.0 module on a Red Hat system it will now segfault
randomly and obscurely on a Debian system because you've failed to DTRT.
If you change the soname and MMN it will fail in the runtime linker as
expected. This is not rocket science.
The community ends up having to deal with the fallout of this stuff, not
you, when the bug reports come in e.g. as they did yesterday to
subversion list, and as they do to the apache.org bug systems for people
using the Debian Apache 1.3 package which is similarly broken.
> How is that different from, say, forcing GCC or even glibc to always use
> 64 bit offsets?..
>
> > In light of what? The fact that there exists some minority
> > distributions
> > already doing the wrong thing? If you change the ABI you *must* change
> > the major MMN. That is what it is *for*.
>
> Yet, according to the header where it's defined, the major MMN is used
> for feature flagging and checking, which would break horribly if we
> picked some random MMN. Pick one lower than the current one, and we're
> advertising a lack of features, pick one higher, and we may be
> advertising a feature set from CVS that we don't actually have.
The numbers between 20020903 and 20030213 are all unused, pick one of
them. Modules will only use MMN numbers from the offical ap_mmn.h in
AP_MODULE_MAGIC_AT_LEAST macros, they don't pick random numbers, so
using e.g. 20041010 should not cause problems. Yes, there is a small
risk that some modules will break but that's the price you pay for
inventing your own ABI rather than using the one we defined upstream.
> I've spent a great deal of time hunting down and squishing such
> problems, yes. I'm fairly confident that we've managed to work around
> all but two, and those are on my plate for the next day or two.
You've fixed /usr/bin/apr-config already then, which won't be exporting
-D_FILE_OFFSET_BITS=64 in --cppflags? And you've found the
incompatibilities between neon and Subversion, everything and zlib?
Regards,
joe
Reply to: