Package: check
Version: 0.9.3-1
Severity: important
Hi,
check is built as a static object, and is meant to be used in
libraries. While Debian policy mandates using -fPIC for shared libs
only, I request that check be built with -fPIC to permit linking on
x86_64. Alternatively, you can consider shipping a shared version of
libcheck.
This change is very important for GStreamer as it FTBFS with check on
x86_64 and won't work.
This has been requested against Fedora and Ubuntu. Fedora did the
change to solve 64 bits build failures, and Ubuntu has bug:
<https://launchpad.net/distros/ubuntu/+source/check/+bug/5840>
Here is the abstract of the IRC conversation I had on the topic with
GStreamer upstream:
17:22 < wingo-pb> when i build check for amd64
17:22 < wingo-pb> on debian,
17:22 < wingo-pb> i have to apt-get source and rebuild it with CFLAGS=-fPIC
17:22 < wingo-pb> it is a problem in the packaging of the check project
17:26 < wingo-pb> also in seb128's packages he must not have
libgstcheck-0.10.so packaged
17:26 < wingo-pb> or else he would have fixed it
17:26 < wingo-pb> those libraries need to be packaged as well, they're utility
libraries from the core that are used in unit tests for other
modules, and are part of public api
17:27 < lool> it's built as a .a static lib in Debian
17:29 < wingo-pb> yes we link it into a .so
17:29 < wingo-pb> so for that reason it has to be compiled as PIC
17:30 < lool> wingo-pb: that's a problem with Debian policy :(
17:30 < lool> "The shared version of a library must be compiled with -fPIC, and
the static version must not be. In other words, each source unit
(*.c, for example, for C files) will need to be compiled twice."
17:31 < wingo-pb> then compile a shared version of check :)
17:31 < lool> wingo-pb: do you have any information on what other distros are
doing with check?
17:32 < wingo-pb> lool: not sure; you could check fedora core, which appears to
have no issues in this regard
17:32 < thomasvs> it had issues
17:32 < thomasvs> it updated to compile the .a with -fPIC
17:32 < thomasvs> now the issues are gone
17:33 < lool> I'm curious on whether they have a shared lib
17:33 < thomasvs> no, they don't atm
17:33 < lool> thomasvs: so they only have a .a, and it is now built with -fPIC?
17:43 < lool> what kind of problem may I encounter if check isn't built with
-fPIC? huge memory consumption because plugins are duplicated in
memory?
17:44 < thomasvs> lool: check is the unit testing stuff we use
17:44 < lool> yes
17:44 < thomasvs> it is not used by gstreamer itself
17:44 < thomasvs> it does not affect plugins
17:44 < lool> hmm it's in a separate .so anyway
17:44 < thomasvs> yes
17:44 < lool> thomasvs: so what was the issue on fedora?
17:44 < thomasvs> it was not built with -fPIC
17:44 < thomasvs> and builds on 64 bit failed on it
17:45 < lool> thomasvs: is this a binutils limitation on x86_64 or so?
17:46 < thomasvs> lool: noidea
17:47 < lool> thomasvs: while I'm trusting your judgment that it would be best
to build with -fPIC, I only see a potential bug failure and hence
possibly a larger bug in binutils to motivate the change, that's
a bit thin :-/
17:50 < wingo-pb> lool: libgstcheck-0.10.so will not build without check being
PIC
17:50 < wingo-pb> so if check is not PIC you cannot package part of gstreamer\
17:52 < lool> wingo-pb: my problem is with the "libgstcheck-0.10.so will not
build without check being PIC" part then
17:52 < wingo-pb> yes
17:52 < lool> wingo-pb: do you know why?
17:52 < wingo-pb> gah...
17:52 < wingo-pb> ok for the nth time :)
17:52 < wingo-pb> libgstcheck is a dynamic library
17:53 < lool> wingo-pb: yes
17:53 < wingo-pb> it needs to be PIC because it's an .so
17:53 < lool> yes and no
17:53 < wingo-pb> it links to libcheck, from the check package.
17:53 < lool> it can be built as non-PIC, but that's to be avoided
17:53 < wingo-pb> right
17:53 < wingo-pb> anyway to make a PIC libgstcheck, libcheck has to be PIC as
well.
17:53 < lool> does something technically prevent it to be built as non-PIC?
17:53 < wingo-pb> why are you interested in hacks?
17:54 < wingo-pb> check should have a PIC library installed; that is the bug.
17:54 < lool> wingo-pb: I need strong justification on why that's needed, I'm
asking another maintainer to transgress policy
17:55 < lool> wingo-pb: what would I break if I built a libgstcheck with
non-PIC code?
17:55 < wingo-pb> lool: not sure. the question would be, what would break if
you built any library with non-PIC code?
17:55 < lool> wingo-pb: that's forbidden in Debian because of memory consumption
17:55 < thomasvs> lool: apparently, symbol relocation
17:56 < MikeS> PIC code does not use more memory.
17:56 < MikeS> It may sometimes run slower on some systems, as it requires an
extra register to be reserved.
17:56 < lool> thomasvs: right, so there would be more memory consumed to load
multimple version of .sos built against libcheck.a
17:56 < wingo-pb> MikeS: it can't be shared between processes
17:56 < lool> MikeS: ...
17:56 < MikeS> wingo-pb: eh?
17:57 < wingo-pb> because the addresses are different
17:57 < wingo-pb> iirc
17:57 < thomasvs> lool: how many of these .so's do you expect there to be, and
actually have an impact on running a machine ?
17:57 < thomasvs> lool: remember, this is a *unit test* framework, not an
application
17:57 < wingo-pb> anyway that's not the issue. why not just get check to
install a libcheck.so??
17:57 < lool> thomasvs: *exactly* so I don't care about memory it takes
17:57 < lool> thomasvs: and hence I can happily leave it building without -fPIC
you see
17:58 < MikeS> wingo-pb: I think you're getting it backwards
17:58 < thomasvs> lool: eh ? that sounds the other way around
17:58 < thomasvs> lool: if memory consumption is not an issue for this package,
why not just build with -fPIC if that makes it actually work ?
17:58 < lool> wingo-pb: if it isn't there, there's probably a reason, such as
lack of upstream support for that
17:58 < thomasvs> lool: or it is not there because the check maintainer never
builds on x86_64 ?
17:58 < thomasvs> or does not expect it to be built into an .so
17:59 < thomasvs> or any number of reasons
17:59 < lool> thomasvs: from my PoV: it's hard to request building with PIC,
and the only drawback of the current non-PIC might be memory
consumption which we don't care about => why build with PIC?
17:59 < MikeS> with PIC, you don't need to rewrite your memory image, because
you can just use it as-is. _WITHOUT_ PIC, you need to relocate
everything, so you can no longer share the code amongst multiple
processes. I think.
17:59 < lool> MikeS: yes, thanks, that's what I said
18:00 < thomasvs> lool: ok; so build it without PIC, then build gstreamer on
x86_64, run make check, and see if it works
18:00 < MikeS> lool: no, it's exactly the opposite of what you said
18:00 < thomasvs> lool: I have a hunch it will not
18:00 < wingo-pb> i suspect upstream just hasn't considered the possibility of
having a check dynamic library. i bet we could fix that.
18:00 < lool> thomasvs: run or build?
18:00 < lool> thomasvs: and if it doesn't, why?
18:00 < thomasvs> lool: leaving you with two options; recompile libcheck.a with
-fPIC, or building libcheck.so
18:01 < thomasvs> lool: run *and* build.
18:01 < thomasvs> lool: and I don't know why. I like solutions that work and
people tell me are correct.
18:01 < MikeS> The problem we have with libcheck is that it's non-PIC code in a
shared library. binutils only supports that on some
architectures (like x86), and not on others (like x86-64
18:01 < thomasvs> lool: my life is short, I can't be bothered to investigate
every little detail.
18:02 < lool> thomasvs: I ask because I'm requesting someone to transgress
policy, and I have to be convincing, that's why, I personally
don't care more on the technical details, I simply need a clue
18:02 < thomasvs> lool: MikeS just gave you the best explanation
18:03 < thomasvs> if you want it to be .a, and work on 64-bit, you need to
compile with -fPIC
18:03 < MikeS> lool: can you explain the policy? You claimed before that it's
because "PIC uses more memory". That's untrue - if multiple
processes are using the same shared library, MORE will be shared
if (and only if) the code is PIC. So that can't be the
justification.
18:03 < thomasvs> if you want it to be a .so, make it a .so, and it should work
18:03 < thomasvs> if you want it to be a .a, and not compile with -fPIC, it's
18:04 < MikeS> thomasvs: not precisely. More correctly: if you want it to be
linkable into a dynamic library (regardless of whether it ITSELF
is a dynamic library), then on x86-64 it must be compiled as PIC
18:04 < lool> MikeS: that's the other way around
18:04 < MikeS> lool: No.
18:04 < lool> MikeS: it's you getting me backward, please scroll back
18:04 < lool> MikeS: I said policy was to use PIC
18:04 < MikeS> lool: Please educate yourself as to how dynamic linking and
relocations work.
18:05 < thomasvs> lool: if policy is to use PIC, then what are we discussing ?
18:05 < lool> MikeS: please educate yourself to respect the person you're
talking to, have a look in your buffer, and you'll see I never
said -fPIC takes more memory
18:05 < thomasvs> follow the policy, compile libcheck.a with -fPIC, and done.
18:05 < lool> thomasvs: it is to use PIC for *shared* libraries
18:05 < lool> and not for static ones
18:06 < MikeS> lool: sorry, maybe that was everyone else.
18:06 < thomasvs> lool: sigh. if your policy forbids you to compile libcheck.a
with -fPIC, then make a .so
18:06 < MikeS> lool: this policy is broken for platforms that don't implement
relocations for non-PIC code in shared libraries. x86-64 is such
a platform. Your policy is broken there, then.
18:06 < thomasvs> lool: why are we going in circles ? you have three options,
one of those three does not work for 64 bit
18:07 < thomasvs> lool: pick door number 1 or 3, stay away from door 2
18:07 < lool> thomasvs: I'm not going in circle, no one told me what breaks, I
know what you want me to ask, but not _technically_ why
18:07 < lool> the reason you invoke is "it works like this"
18:07 < lool> that's not enough to convinve someone else
18:07 < lool> even if I trust you
18:07 < thomasvs> right. but MikeS provided the explanation on why my magic
wand happens to work
18:07 < thomasvs> I trust MikeS's assessment of the situation
18:08 < thomasvs> what more info do you need ?
18:08 < MikeS> lool: I misread something you said before; it was a little
unclear because of the context. You're right, you didn't say PIC
takes more memory. My apologies.
18:08 < lool> thomasvs: it's enough if you tell me you trust MikeS here :)
18:08 < lool> MikeS: let's get on with this
18:08 < thomasvs> lool: ok. I believe Mike when he says that non-PIC code in
shared library relocation is broken on some platforms.
18:08 < thomasvs> he's the only one who can make up shit like that and still
have it sound convincing
18:09 < MikeS> Seriously though, who uses static libraries at all these days?
Most modern systems don't even _provide_ static libraries for
things like libc.
18:09 < MikeS> thomasvs: not broken. Deliberately unimplemented.
18:09 < lool> MikeS: we do for stuff changing rapidly, such as ffmpeg
18:09 < lool> MikeS: we also do for cross-compiles, especially embedded, but I
don't know a lot about that
18:10 < lool> MikeS: I'm a bit surprized by your information on relocatability
of non-PIC shared libs, I'm under the impression that the Debian
archive would have been striked hard in this case, but never saw
any such problem
18:11 < MikeS> Yeah, embedded's a totally different case, and there you'd often
want to statically link the entire system, but it doesn't make
sense to have the same policy for embedded and desktop use
18:11 < lool> MikeS: I'm interested if you have some pointers on that problem
18:12 < MikeS> lool: there are very few things that are provided _only_ as
static libs (libcheck is apparently one of them), so it's
unlikely to cause real difficulties for most things.
18:12 < MikeS> lool: ffmpeg is probably another case, but ffmpeg is usually
statically linked into executables (gstreamer uses its own copy
of ffmpeg, so avoids the debian packaging of that)
18:13 < MikeS> lool: can you think of any other libs provided only in non-PIC,
static form?
18:13 < lool> yes, (I'm packaging gst-ffmpeg BTW)
Cheers,
--
Loïc Minier <[EMAIL PROTECTED]>
Current Earth status: NOT DESTROYED
