[gentoo-dev] supporting static-libs

[gentoo-dev] supporting static-libs

[hasufell]

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?

Re: [gentoo-dev] supporting static-libs

[Diego Elio Pettenò]

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/

Re: [gentoo-dev] supporting static-libs

[Alexandre Rostovtsev]

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.

Re: [gentoo-dev] supporting static-libs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] supporting static-libs

[Gregory M. Turner]

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

Re: [gentoo-dev] supporting static-libs

[Mart Raudsepp]

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

Re: [gentoo-dev] supporting static-libs

[Diego Elio Pettenò]

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/

[gentoo-dev] cygwin: gmp/mpc: package.use.mask static-libs? (was: supporting static-libs)

[Gregory M. Turner]

On 8/28/2012 4:05 PM, Diego Elio Pettenò wrote:
> 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.

In this case, the issue is purportedly that the headers get generated 
differently, depending on whether you build static or dynamic.

I don't think too much, unless I have to, about what kind of 
libtool/gcc/gentoo magic makes it all possible, but by and large, static 
and dynamic libraries "just work" in my overlay.  So if gentoo-prefix 
would create both static and dynamic for a given library on elf, the 
same thing happens in my overlay (I mean that this typically happens 
without any hand-holding, on my part, to make it work).

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

euse -i says:

   static - !!do not set this during bootstrap!! Causes binaries
            to be statically linked instead of dynamically

Pretty sure I've done the right thing in my overlay by masking, but it 
can't hurt to mention that I'm always happy to hear any suggestions or 
ideas (although of course I reserve the right to politely decide that 
your ideas are crap and ignore them :P).

My reasoning for the flag-mask is that Gentoo always builds the dynamic 
libs for these packages and therefore so should my overlay.  Unless I 
fix the underlying conflict or implement some kind of side-by-side 
scheme (a la libncursesw), I really have no choice but to forbid 
building statically (note that cygports adopts the same solution).

Masking the use-flag for the affected atoms accomplishes this 
prohibition exactly, exclusively, and without any kludge (except 
unfortunately I still have to patch the e-build, as, for some goofy 
reason, configure doesn't interpret the static/dynamic options the same 
way after applying the cygports patches -- hopefully I can fix that just 
by leaving some patches out; I just haven't gotten to it yet).

-gmt

Re: [gentoo-dev] supporting static-libs

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 841 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] supporting static-libs

[Brian Harring]

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

Re: [gentoo-dev] supporting static-libs

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 2711 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] supporting static-libs

[Luca Barbato]

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

Re: [gentoo-dev] supporting static-libs

[hasufell]

On 09/22/2012 05:15 PM, Luca Barbato wrote:
> 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
> 

It's a matter of 15minutes work to patch a cmake build system to allow
installation of both.

You can let cmake rename targets, so you have target library "foo" and
"foostatic", but the latter will be renamed to "foo" as well.

e.g.:
add_library(foostatic STATIC foo.cpp foo.h)
set_target_properties(foostatic PROPERTIES OUTPUT_NAME foo)
add_library(foo SHARED foo.cpp foo.h)

Re: [gentoo-dev] supporting static-libs

[Luca Barbato]

On 09/22/2012 05:25 PM, hasufell wrote:

> add_library(foostatic STATIC foo.cpp foo.h)
> set_target_properties(foostatic PROPERTIES OUTPUT_NAME foo)
> add_library(foo SHARED foo.cpp foo.h)

Looks a bit kludgy but should work well as a macro, willing to contact
upstream and/or ask cmake devs to include it? Looks like you have a
simple solution for this problem =)

lu