FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-17-2011, 07:33 AM
Reinhard Tartler
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

tags 622931 help
stop

On Fri, Apr 15, 2011 at 23:48:06 (CEST), Carl Fürstenberg wrote:

> Package: libav
> Severity: minor
>
> Doing an `pkg-config --static libavcodec --libs` results in following
> dependices:
> -pthread -lavcodec -ldl -lX11 -lXext -lXfixes -ljack -lasound -ldc1394
> -lraw1394 -lxvidcore -lx264 -lvpx -lvorbisenc -lvorbis -ltheoraenc
> -ltheoradec -logg -lspeex -lschroedinger-1.0 -lpthread -lorc-0.4 -lrtmp
> -lgnutls -lopenjpeg -lopencore-amrwb -lopencore-amrnb -lmp3lame -lgsm
> -lfaac -ldirac_encoder -ldirac_decoder -lstdc++ -lva -lm -lbz2 -lz -lgcrypt
> -lavcore -lavutil
>
> But libva-dev and libgpg-error-dev (dep via libgcrypt, which also isn't given)
> doesn't provide static versions.
> This might be outside the area provided by debian packages, but might be
> worth looking into.

it rather seems that pkg-config does not provide a way to declare that a
library does not support static linking at all. I've checked that libva
simply doesn't support building static libraries in the first place, so
I've tried to edit the pkg-config file. However, after reading the
pkg-config documentation, I haven't found the right syntax to express
this.

Can someone please help me out here?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r5911gdm.fsf@faui44a.informatik.uni-erlangen.de">http://lists.debian.org/87r5911gdm.fsf@faui44a.informatik.uni-erlangen.de
 
Old 04-17-2011, 05:14 PM
Neil Williams
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

On Sun, 17 Apr 2011 09:33:41 +0200
Reinhard Tartler <siretart@tauware.de> wrote:

> On Fri, Apr 15, 2011 at 23:48:06 (CEST), Carl Fürstenberg wrote:
>
> > Package: libav
> > Severity: minor
> >
> > Doing an `pkg-config --static libavcodec --libs` results in following
> > dependices:
> > -pthread -lavcodec -ldl -lX11 -lXext -lXfixes -ljack -lasound -ldc1394
> > -lraw1394 -lxvidcore -lx264 -lvpx -lvorbisenc -lvorbis -ltheoraenc
> > -ltheoradec -logg -lspeex -lschroedinger-1.0 -lpthread -lorc-0.4 -lrtmp
> > -lgnutls -lopenjpeg -lopencore-amrwb -lopencore-amrnb -lmp3lame -lgsm
> > -lfaac -ldirac_encoder -ldirac_decoder -lstdc++ -lva -lm -lbz2 -lz -lgcrypt
> > -lavcore -lavutil
> >
> > But libva-dev and libgpg-error-dev (dep via libgcrypt, which also isn't given)
> > doesn't provide static versions.
> > This might be outside the area provided by debian packages, but might be
> > worth looking into.
>
> it rather seems that pkg-config does not provide a way to declare that a
> library does not support static linking at all. I've checked that libva
> simply doesn't support building static libraries in the first place, so
> I've tried to edit the pkg-config file. However, after reading the
> pkg-config documentation, I haven't found the right syntax to express
> this.
>
> Can someone please help me out here?

http://lists.freedesktop.org/archives/pkg-config/2007-September/000222.html

> Static builds are one of the cases pkg-config doesn't handle well, as
> it does not record whether a static library is present or not.

Tollef? Any change in that since 2007?

(I'm not expecting such a change as pkg-config doesn't do this for dynamic linkage either, that is left to the package build system. As static is not the default build for most package build systems, it's not unexpected that it simply doesn't work in many cases. Too few people care, too few people to test every single change in the dependency chain.)

Is it possible to define an alternative .pc file which omits libva-dev and libgcrypt? (Even if that means that libav itself needs different ./configure options to be built that way).

If not, maybe this just needs some documentation that static linking for this package - and quite probably many, many others - simply does not work. It's an upstream issue - does upstream care about static linkage? (I'm upstream for a few and I frankly don't care about static linkage in those packages at all. I haven't worked with other upstream teams where I can remember anyone ever expressing interest in static linking either.)

I think it is worth being realistic here. Assuring static linkage support in Debian is, IMHO, simply not attainable for the vast majority of libraries. It's not a fixable problem because not enough people care about it anymore. Changes in static linkage behaviour are not likely to be an ingredient in any Release Team considerations for testing migrations or stable releases, so even if this was done once, it would break almost immediately.

I also think the bug is from a mistaken viewpoint. There is nothing which can be put into a .pc file to imply that static linkage is or is not possible. pkg-config has a --static option but pkg-config doesn't attempt to verify any of the strings it outputs, dynamic or static.

Therefore, libav does not have a pkg-config file which implies possible static linkage. Any package with a .pc file has an implied support for the options which pkg-config supports but that support is only a bug if the package concerned EXPLICITLY declares such support. All packages in Debian can be considered to explicitly support dynamic linking via pkg-config if a .pc file is provided - the same cannot be said for static.

Packages cannot be blamed for lack of support for options made available from tools when those options are not explicitly supported by that particular package.

Certain methods must be supported and, currently, that is dynamic linkage - not static.

IMHO unless every upstream package in the necessary chain states that static linkage is supported by upstream, then static linkage is an "exercise left to the reader" to solve and there's nothing to be done with bugs like this, except possibly state in the packaging docs that static simply does not work "out of the box".

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 04-17-2011, 05:51 PM
Carl Fürstenberg
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

On 2011-04-17 19:14, Neil Williams wrote:
>
> Tollef? Any change in that since 2007?
>
> (I'm not expecting such a change as pkg-config doesn't do this for dynamic linkage either, that is left to the package build system. As static is not the default build for most package build systems, it's not unexpected that it simply doesn't work in many cases. Too few people care, too few people to test every single change in the dependency chain.)
>
> Is it possible to define an alternative .pc file which omits libva-dev and libgcrypt? (Even if that means that libav itself needs different ./configure options to be built that way).
>
> If not, maybe this just needs some documentation that static linking for this package - and quite probably many, many others - simply does not work. It's an upstream issue - does upstream care about static linkage? (I'm upstream for a few and I frankly don't care about static linkage in those packages at all. I haven't worked with other upstream teams where I can remember anyone ever expressing interest in static linking either.)
>
> I think it is worth being realistic here. Assuring static linkage support in Debian is, IMHO, simply not attainable for the vast majority of libraries. It's not a fixable problem because not enough people care about it anymore. Changes in static linkage behaviour are not likely to be an ingredient in any Release Team considerations for testing migrations or stable releases, so even if this was done once, it would break almost immediately.
>
> I also think the bug is from a mistaken viewpoint. There is nothing which can be put into a .pc file to imply that static linkage is or is not possible. pkg-config has a --static option but pkg-config doesn't attempt to verify any of the strings it outputs, dynamic or static.
>
> Therefore, libav does not have a pkg-config file which implies possible static linkage. Any package with a .pc file has an implied support for the options which pkg-config supports but that support is only a bug if the package concerned EXPLICITLY declares such support. All packages in Debian can be considered to explicitly support dynamic linking via pkg-config if a .pc file is provided - the same cannot be said for static.
>
> Packages cannot be blamed for lack of support for options made available from tools when those options are not explicitly supported by that particular package.
>
> Certain methods must be supported and, currently, that is dynamic linkage - not static.
>
> IMHO unless every upstream package in the necessary chain states that static linkage is supported by upstream, then static linkage is an "exercise left to the reader" to solve and there's nothing to be done with bugs like this, except possibly state in the packaging docs that static simply does not work "out of the box".
>

It seems I've missunderstod some aspects of the features of pkg-config.
I assumed as there are Requires.private and Libs.private, that there was
some way to specify that static linkage was not possible at all.

Perhaps an bug on pkg-config should be open to add option to prohibit
static linkage.
 
Old 04-17-2011, 06:27 PM
Neil Williams
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

On Sun, 17 Apr 2011 19:51:12 +0200
Carl Fürstenberg <azatoth@gmail.com> wrote:

> It seems I've missunderstod some aspects of the features of pkg-config.
> I assumed as there are Requires.private and Libs.private, that there was
> some way to specify that static linkage was not possible at all.

You mean other than letting the defaults just happen and document in
the package that the defaults simply won't work? There's no such method
AFAICT.

> Perhaps an bug on pkg-config should be open to add option to prohibit
> static linkage.

There's nothing in pkg-config to say that dynamic linking for any one
package will always work, why should static be any different? (e.g.
pkg-config will continue to report data which relates to versions of
packages which no longer exist simply because the original package
hasn't been updated. Yes, in Debian that will cause a FTBFS but that's
nothing to do with pkg-config.)

pkg-config is just config, it is not a pkg checker. Checking that what
you get actually works has to come down to the actual package. Even
then, unless that config is supported, it will (and must be allowed
to) just fail to build.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 04-17-2011, 07:43 PM
Reinhard Tartler
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

retitle 622931 Possibility to express linking modes
reassign 622931 pkg-config
stop

Neil, thank you very much for your insightful summary of the matter. Now
it seems pretty clear that this issue cannot be handled in the libav
package, but needs to be solved at the pkg-config level. I'm therefore
reassigning this bug to pkg-config.

Full context follows:

On Sun, Apr 17, 2011 at 20:27:03 (CEST), Neil Williams wrote:

> On Sun, 17 Apr 2011 19:51:12 +0200
> Carl Fürstenberg <azatoth@gmail.com> wrote:
>
>> It seems I've missunderstod some aspects of the features of pkg-config.
>> I assumed as there are Requires.private and Libs.private, that there was
>> some way to specify that static linkage was not possible at all.
>
> You mean other than letting the defaults just happen and document in
> the package that the defaults simply won't work? There's no such method
> AFAICT.
>
>> Perhaps an bug on pkg-config should be open to add option to prohibit
>> static linkage.
>
> There's nothing in pkg-config to say that dynamic linking for any one
> package will always work, why should static be any different? (e.g.
> pkg-config will continue to report data which relates to versions of
> packages which no longer exist simply because the original package
> hasn't been updated. Yes, in Debian that will cause a FTBFS but that's
> nothing to do with pkg-config.)
>
> pkg-config is just config, it is not a pkg checker. Checking that what
> you get actually works has to come down to the actual package. Even
> then, unless that config is supported, it will (and must be allowed
> to) just fail to build.

Cheers!

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mxjooe9a.fsf@faui44a.informatik.uni-erlangen.de">http://lists.debian.org/87mxjooe9a.fsf@faui44a.informatik.uni-erlangen.de
 
Old 04-17-2011, 09:30 PM
Tollef Fog Heen
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

]] Reinhard Tartler

| Neil, thank you very much for your insightful summary of the matter. Now
| it seems pretty clear that this issue cannot be handled in the libav
| package, but needs to be solved at the pkg-config level. I'm therefore
| reassigning this bug to pkg-config.

Just to make it clear, what you want is a way for a package (libA) to
say «you can't build this statically»? If so, there's no way to do that
with pkg-config and unless you can convince me what the use case is and
why this is worth supporting, I'm not going to add it.

Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87liz84lc5.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87liz84lc5.fsf@qurzaw.varnish-software.com
 
Old 04-18-2011, 07:00 AM
Neil Williams
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

On Sun, 17 Apr 2011 23:30:34 +0200
Tollef Fog Heen <tfheen@err.no> wrote:

> ]] Reinhard Tartler
>
> | Neil, thank you very much for your insightful summary of the matter. Now
> | it seems pretty clear that this issue cannot be handled in the libav
> | package, but needs to be solved at the pkg-config level. I'm therefore
> | reassigning this bug to pkg-config.
>
> Just to make it clear, what you want is a way for a package (libA) to
> say «you can't build this statically»? If so, there's no way to do that
> with pkg-config and unless you can convince me what the use case is and
> why this is worth supporting, I'm not going to add it.

Perhaps a little statement in pkg-config (1) in the section on --static
which makes it clear that pkg-config (just as with the default
'--dynamic' output) does not check this data and whether it works or
not is undetermined?

"Not all libraries support static linking and some libraries may still
require other steps to allow programs to statically link using the
output of pkg-config --static."

Maybe also a statement in the main description that pkg-config does not
(cannot) check whether the data in the .pc file(s) will actually allow
programs to link against the libraries specified. That is the job of
the build system using pkg-config. pkg-config is, after all, a config
tool, not a QA or checking tool.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 04-18-2011, 08:05 AM
Neil Williams
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

On Mon, 18 Apr 2011 09:22:09 -0700
Fabian Greffrath <fabian@greffrath.com> wrote:

> Am 17.04.2011 12:43, schrieb Reinhard Tartler:
> > Neil, thank you very much for your insightful summary of the matter. Now
> > it seems pretty clear that this issue cannot be handled in the libav
> > package, but needs to be solved at the pkg-config level. I'm therefore
> > reassigning this bug to pkg-config.
>
> Couldn't we simply drop the *.private fields in the .pc files to
> signalize we don't support static linking?

It's the dependency of the dependency of one of the Requires fields
which causes the breakage, not the Requires.private. i.e. the
Requires.private can be right but the static linkage can still fail.

Lack of Requires.private is no indicator of a lack of support for
--static. There are many libraries which could link statically but
which have no need for any data in Requires.private.

Dropping the Requires.private in libav doesn't signify anything - it
merely hides the real problem in the dependency chain. (A problem which
does not necessarily *have* a fix because static linkage is a corner
case.)

I appreciate that pkg-config and libav can both document this issue a
bit more usefully but nobody in this thread has so far given a robust
use case for changes in the code for either libav or pkg-config.

The original package (libav) doesn't link statically - fine, it isn't
explicitly supported so it doesn't have to work and the only problem
that has been described lies outside the remit of the libav package
itself.

Equally, pkg-config is not the place to go around checking whether the
supplied configuration actually works. pkg-config makes no pretence at
being the "one-stop-solution" for all your linking requirements,
although it can do most of the work most of the time - even for dynamic
linking there are times when it's not just the lack of a .pc file which
causes developers to need to add other stuff to the output of
pkg-config.

The problem simply has to lie with the build system which is trying to
generate a static linkage. i.e. the problem isn't in libav, it isn't
in pkg-config. Those two can *document* possible reasons why static
linkage might not work in all cases but it isn't their problem when it
does fail.

Static just isn't universally supported / supportable. That puts the
burden firmly on those who want to link statically. There will be hacks
and changes needed in the build system of whatever is trying to
generate a static build and that is where these problems need to be
fixed. Maybe those hacks will include parsing the output of pkg-config
--static to make allowances for those dependencies which cannot link
statically. It won't be the last time that's going to be needed.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 04-18-2011, 12:09 PM
Ben Hutchings
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

On Mon, 2011-04-18 at 09:05 +0100, Neil Williams wrote:
> On Mon, 18 Apr 2011 09:22:09 -0700
> Fabian Greffrath <fabian@greffrath.com> wrote:
>
> > Am 17.04.2011 12:43, schrieb Reinhard Tartler:
> > > Neil, thank you very much for your insightful summary of the matter. Now
> > > it seems pretty clear that this issue cannot be handled in the libav
> > > package, but needs to be solved at the pkg-config level. I'm therefore
> > > reassigning this bug to pkg-config.
> >
> > Couldn't we simply drop the *.private fields in the .pc files to
> > signalize we don't support static linking?
>
> It's the dependency of the dependency of one of the Requires fields
> which causes the breakage, not the Requires.private. i.e. the
> Requires.private can be right but the static linkage can still fail.
>
> Lack of Requires.private is no indicator of a lack of support for
> --static. There are many libraries which could link statically but
> which have no need for any data in Requires.private.
[...]

Libs.private = -fstatic-linking-is-not-supported

;-)

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-18-2011, 04:22 PM
Fabian Greffrath
 
Default Bug#622931: libav: pkg-config files implies possible static linkage

Am 17.04.2011 12:43, schrieb Reinhard Tartler:

Neil, thank you very much for your insightful summary of the matter. Now
it seems pretty clear that this issue cannot be handled in the libav
package, but needs to be solved at the pkg-config level. I'm therefore
reassigning this bug to pkg-config.


Couldn't we simply drop the *.private fields in the .pc files to
signalize we don't support static linking?


- Fabian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DAC6531.60307@greffrath.com">http://lists.debian.org/4DAC6531.60307@greffrath.com
 

Thread Tools




All times are GMT. The time now is 08:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org