Le mercredi 05 mai 2010 à 12:18 +0200, Simon Richter a écrit :
> Gtk would also need to include the SONAME from glib into their own,
> given that ABI breaks in glib also implicitly break their own ABI.
The GTK+ ABI stability guarantees are the same as the GLib ones. The
SONAMEs can only be changed
Hi,
On Wed, May 05, 2010 at 11:51:09AM +0200, Samuel Thibault wrote:
> A lot of gtk headers use GObjectClass types, macros and such, which are
> from Glib. You thus need both glib headers and libraries.
Gtk would also need to include the SONAME from glib into their own,
given that ABI breaks in
Hendrik Sattler, le Wed 05 May 2010 10:47:24 +0200, a écrit :
> Zitat von Josselin Mouette :
>
> >Le mardi 04 mai 2010 à 10:31 +0200, Emilio Pozuelo Monfort a écrit :
> >>Sorry I don't know what you're talking about. If you can explain it
> >> I'll try to
> >>look at the problem.
> >
> >It’s not
Zitat von Josselin Mouette :
Le mardi 04 mai 2010 à 10:31 +0200, Emilio Pozuelo Monfort a écrit :
Sorry I don't know what you're talking about. If you can explain it
I'll try to
look at the problem.
It’s not a problem, it’s a disagreement over a design choice.
When you do that:
#i
Le mardi 04 mai 2010 à 10:31 +0200, Emilio Pozuelo Monfort a écrit :
> Sorry I don't know what you're talking about. If you can explain it I'll try
> to
> look at the problem.
It’s not a problem, it’s a disagreement over a design choice.
When you do that:
#include
you’re able to use g
]] Paul Wise
| On Mon, May 3, 2010 at 4:46 PM, Tollef Fog Heen wrote:
|
| > | And GNOME developers insistance (so applications developers may
| > | blindly include gtk+2.0.pc and get all the stack).
| >
| > Yes, historical baggage, basically.
|
| So this is being fixed for GTK+ 3.0?
I don't b
On 03/05/10 10:46, Tollef Fog Heen wrote:
> ]] Mikhail Gusarov
> | And GNOME developers insistance (so applications developers may
> | blindly include gtk+2.0.pc and get all the stack).
>
> Yes, historical baggage, basically.
Sorry I don't know what you're talking about. If you can explain it I'
On Mon, May 3, 2010 at 4:46 PM, Tollef Fog Heen wrote:
> | And GNOME developers insistance (so applications developers may
> | blindly include gtk+2.0.pc and get all the stack).
>
> Yes, historical baggage, basically.
So this is being fixed for GTK+ 3.0?
--
bye,
pabs
http://wiki.debian.org/Pa
]] Mikhail Gusarov
| Twas brillig at 23:54:02 02.05.2010 UTC+04 when yo...@debian.org did gyre and
gimble:
|
| >> For #includes that your library may do for its API (e.g. gobject).
|
| NVY> But libetpan's public headers do not include any headers of those
dependent
| NVY> packages, so it
Josselin Mouette writes:
> Le dimanche 02 mai 2010 à 11:57 -0500, Steve M. Robbins a écrit :
>> One example is scientific users that need to ensure reproducibility of
>> computer experiments [1] over many years: one technique used is to
>> statically link the code and quarantine it so that it
Le dimanche 02 mai 2010 à 11:57 -0500, Steve M. Robbins a écrit :
> One example is scientific users that need to ensure reproducibility of
> computer experiments [1] over many years: one technique used is to
> statically link the code and quarantine it so that it isn't disturbed
> by system librar
Twas brillig at 23:54:02 02.05.2010 UTC+04 when yo...@debian.org did gyre and
gimble:
>> For #includes that your library may do for its API (e.g. gobject).
NVY> But libetpan's public headers do not include any headers of those
dependent
NVY> packages, so it is not the case.
NVY> Any othe
Nikita V. Youshchenko, le Sun 02 May 2010 23:54:02 +0400, a écrit :
> > > > > > Static linking is resolved by providing a foo.pc file so that
> > > > > > "pkg-config --static --libs foo" is all that's needed to find
> > > > > > the right libs.
> > > > >
> > > > > This does not clarify the question
> > > > > Static linking is resolved by providing a foo.pc file so that
> > > > > "pkg-config --static --libs foo" is all that's needed to find
> > > > > the right libs.
> > > >
> > > > This does not clarify the question about dependences.
> > >
> > > It does, because foo.pc won't work without its
Nikita V. Youshchenko, le Sun 02 May 2010 21:18:26 +0400, a écrit :
> > On Sun, May 2, 2010 at 15:30:37 +0400, Nikita V. Youshchenko wrote:
> > > > On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote:
> > > > > (To actually statically link without the .la (or with an .la
> > > > > 'mangled
> I wouldn't
> necessarily downgrade the -dev package dependencies: often they are
> there not only for the static lib, but also because your library's
> includes will #include files from other libs it depends on, so all
> users of your -dev package may need the depended-upon -devs. So it
> will d
> On Sun, May 2, 2010 at 15:30:37 +0400, Nikita V. Youshchenko wrote:
> > > On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote:
> > > > (To actually statically link without the .la (or with an .la
> > > > 'mangled' to empty the dependency_libs field) largely amounts to
> > > > reconstruct
I'm a little alarmed at the attitude that "no one cares about static
linking" so that it's okay to drop the .a files. Likely relatively
few people care, but there are some that do.
One example is scientific users that need to ensure reproducibility of
computer experiments [1] over many years: one
Neil Williams wrote:
> But does any package in Debian actually do the static linking?
A few udebs use static linking to avoid the need for separate udebs for
certain libraries. It also helps to reduce memory usage as only needed
symbols are linked in.
It's only used in a few specific cases; the
On Sun, May 2, 2010 at 15:30:37 +0400, Nikita V. Youshchenko wrote:
> > On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote:
> > > (To actually statically link without the .la (or with an .la 'mangled'
> > > to empty the dependency_libs field) largely amounts to reconstructing
> > > the i
* Nikita V. Youshchenko [100502 11:27]:
> (3) looks like plain inconsistency: package will provide .a file, but not
> ensure things required for using .a file into system.
I think (3) is the best you can do if you assume the .a file is usefull
to anyone. If someone wants to link to the .a file, t
> On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote:
> > (To actually statically link without the .la (or with an .la 'mangled'
> > to empty the dependency_libs field) largely amounts to reconstructing
> > the information that was in the .la originally. That should be
> > sufficient disin
On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote:
> (To actually statically link without the .la (or with an .la 'mangled'
> to empty the dependency_libs field) largely amounts to reconstructing
> the information that was in the .la originally. That should be
> sufficient disincentive t
On Sun, 2 May 2010 13:17:08 +0400
"Nikita V. Youshchenko" wrote:
> I'm going to unload a new version, and, among other things, I was
> going to remove .la file, per release-goal
(Thanks for the reminder, the lack of a bug report led to me completely
forgetting that I meant to do something about
Hi
I maintain a library package, libetpan.
I'm going to unload a new version, and, among other things, I was going to
remove .la file, per release-goal
In http://ftp-master.debian.org/~aba/la/current.txt, package is listed
as 'libetpan: dependency_libs', so I thoughty I just need to remove .la
25 matches
Mail list logo
