Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   supporting static-libs (http://www.linux-archive.org/gentoo-development/698267-supporting-static-libs.html)

Diego Elio Pettenò 08-28-2012 12:44 AM

supporting static-libs
 
On 27/08/2012 17:15, hasufell wrote:
> Is there a reason not to support static-libs in an ebuild if the package
> supports it?

Most libtool software "supports" static-libs, because libtool let you
build them, _but_ it might not be test or might not even work.

One example is software that relies on plug-ins, such as xine-lib. or
stuff that links to gmodule. Having static libraries there is
technically possible, but if you do you have a bag full of problems and
nothing else.

> It seems some developers don't care about this option. What's the gentoo
> policy on this? Isn't this actually a bug?

I honestly don't usually put static-libs "just because" — if a case can
be made about static libs to be useful, I'm always open to add an USE
flag, but "because I can" is not an option for me.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Alexandre Rostovtsev 08-28-2012 01:27 AM

supporting static-libs
 
On Tue, 2012-08-28 at 02:15 +0200, hasufell wrote:
> Is there a reason not to support static-libs in an ebuild if the package
> supports it?
>
> It seems some developers don't care about this option. What's the gentoo
> policy on this? Isn't this actually a bug?

For example, static linking is disabled in gtk+, pango, and gdk-pixbuf
because they heavily rely on plugin loading. And anything that links to
gtk+ should not be using static linking unless it wants to crash a lot.

Michał Górny 08-28-2012 08:09 AM

supporting static-libs
 
On Tue, 28 Aug 2012 02:15:40 +0200
hasufell <hasufell@gentoo.org> wrote:

> Is there a reason not to support static-libs in an ebuild if the
> package supports it?
>
> It seems some developers don't care about this option. What's the
> gentoo policy on this? Isn't this actually a bug?

Some people believe that IUSE=static-libs should be always used,
I think, and they consider that to be a Gentoo policy.

I believe that this is pointless to add it to every single library
noone will ever use as static. I do add them when it's simple (i.e.
with autotools-utils) and I know the package is supposed to work when
linked statically. Otherwise, I'd just wait for someone to request
static-libs support, much like we don't keyword ahead.

--
Best regards,
Michał Górny

"Gregory M. Turner" 08-28-2012 10:18 PM

supporting static-libs
 
On 8/28/2012 1:09 AM, Michał Górny wrote:

On Tue, 28 Aug 2012 02:15:40 +0200
hasufell <hasufell@gentoo.org> wrote:

static-libs

pointless


I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay,
where one can have static or dynamic, but not both, as per. upstream
requirements (no idea why). So FTR, this is not always a matter of
personal taste.


-gmt

Mart Raudsepp 08-28-2012 10:36 PM

supporting static-libs
 
On N, 1970-01-01 at 00:00 +0000, Gregory M. Turner wrote:
> On 8/28/2012 1:09 AM, Michał Górny wrote:
> > On Tue, 28 Aug 2012 02:15:40 +0200
> > hasufell <hasufell@gentoo.org> wrote:
> >> static-libs
> > pointless
>
> I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay,
> where one can have static or dynamic, but not both, as per. upstream
> requirements (no idea why). So FTR, this is not always a matter of
> personal taste.

static-libs is for installing static libraries IN ADDITION to shared
libraries, not instead.
USE=static is for what you have in mind there.


Best,
Mart Raudsepp

Diego Elio Pettenò 08-28-2012 11:05 PM

supporting static-libs
 
On 28/08/2012 15:36, Mart Raudsepp wrote:
> static-libs is for installing static libraries IN ADDITION to shared
> libraries, not instead.
> USE=static is for what you have in mind there.

PE is not the same as ELF so on Windows you either build one or the
other for a number of reasons.

Now on a different note, this is not even what USE=static is for — but
that's way behind what we were discussing before.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Maciej Mrozowski 09-03-2012 08:54 PM

supporting static-libs
 
On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
> Is there a reason not to support static-libs in an ebuild if the package
> supports it?
>
> It seems some developers don't care about this option. What's the gentoo
> policy on this? Isn't this actually a bug?

A little remark.
For CMake controlled buildsystem (as you're coming here from latest dev-
games/simgear), there's no automatic way of building both static and shared
libs (simgear allows to choose just one).
This is why I removed static libs support that you proposed for dev-
games/simgear (similar to ruby eclass abi handling - manually calling phases
twice to build package 1st as shared, 2nd time as static).
This is what I called "not worth the effort" in private discussion with you,
not quite "I don't care for static libs" :)

--
regards
MM

Brian Harring 09-06-2012 08:18 AM

supporting static-libs
 
On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote:
> On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
> > Is there a reason not to support static-libs in an ebuild if the package
> > supports it?
> >
> > It seems some developers don't care about this option. What's the gentoo
> > policy on this? Isn't this actually a bug?
>
> A little remark.
> For CMake controlled buildsystem (as you're coming here from latest dev-
> games/simgear), there's no automatic way of building both static and shared
> libs (simgear allows to choose just one).
> This is why I removed static libs support that you proposed for dev-
> games/simgear (similar to ruby eclass abi handling - manually calling phases
> twice to build package 1st as shared, 2nd time as static).
> This is what I called "not worth the effort" in private discussion with you,
> not quite "I don't care for static libs" :)

Guessing in the worst case, you can do a double compile to get around
this, no? And yes, that's freaking horrible, just verifying cmake
isn't doing something special that blocks it.

Is upstream doing anything about this, or is it not on their
radar/list-of-things-they-care-about ?

~harring

Maciej Mrozowski 09-21-2012 11:47 PM

supporting static-libs
 
On Thursday 06 of September 2012 10:18:34 Brian Harring wrote:
> On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote:
> > On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
> > > Is there a reason not to support static-libs in an ebuild if the
> > > package supports it?
> > >
> > > It seems some developers don't care about this option. What's the
> > > gentoo policy on this? Isn't this actually a bug?
> >
> > A little remark.
> > For CMake controlled buildsystem (as you're coming here from latest dev-
> > games/simgear), there's no automatic way of building both static and
> > shared libs (simgear allows to choose just one).
> > This is why I removed static libs support that you proposed for dev-
> > games/simgear (similar to ruby eclass abi handling - manually calling
> > phases twice to build package 1st as shared, 2nd time as static).
> > This is what I called "not worth the effort" in private discussion with
> > you, not quite "I don't care for static libs" :)
>
> Guessing in the worst case, you can do a double compile to get around
> this, no? And yes, that's freaking horrible, just verifying cmake
> isn't doing something special that blocks it.

Not sure why they would need to block it, one build dir for static, second one
for shared. All safely separated (still stinks as a hack).

> Is upstream doing anything about this, or is it not on their
> radar/list-of-things-they-care-about ?

Off the radar.

CMake provides equivalent of '--enable-static --disable-shared' and '--
disable-static --enable-shared' by the means of BUIlLD_SHARED_LIBS and not
specifying linkage when defining library:

add_library(foo src1 src2)

It doesn't automatically provide both at the same time however. CMake is
cross-platform (meaning it support different generators: GNU Make, NMake,
Visual Studio Project, XCode etc) so their main audience aren't "distros",
also on Windows for instance when shared .dll is created, also import .lib is
created. If static .lib was to be created as well, they would need to have
separate build subdir for it (and a bit more complex library resolution
algorithm).

Still, if developer bothers enough to provide them both, he can easily
implement it in buildsystem with explicitly given linkage (and separate target
names):

set(foo_SRC src1 src2)
add_library(foo SHARED ${foo_SRC})
if (ENABLE_STATIC)
add_library(foo_static STATIC ${foo_SRC})
endif ()

That being said I can understand why it's off the radar - technically
everything is already available, likely not worth the effort and in many cases
building both static/shared is actually not needed.

--
regards
MM

Luca Barbato 09-22-2012 03:15 PM

supporting static-libs
 
On 09/03/2012 10:54 PM, Maciej Mrozowski wrote:
> On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
>> Is there a reason not to support static-libs in an ebuild if the package
>> supports it?
>>
>> It seems some developers don't care about this option. What's the gentoo
>> policy on this? Isn't this actually a bug?
>
> A little remark.
> For CMake controlled buildsystem (as you're coming here from latest dev-
> games/simgear), there's no automatic way of building both static and shared
> libs (simgear allows to choose just one).

Complain to cmake devs, hopefully they might come up with a solution.
(the alternative is provide a clean autotools-based build system and ask
upstream to please keep both. Usually works nice to cover all bases and
make all people happy ^^;

lu


All times are GMT. The time now is 09:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.