On Tue, 05 Oct 2010 04:13:04 +0200
Diego Elio Pettenò flamee...@gmail.com wrote:
I'm going instead to link my latest blog post on the matter where I
summarised most of the points. Why a blog post? Because so I have it
available as reference for the future together with all the others.
Don't
On 10/04/2010 09:13 PM, Duncan wrote:
Zac Medico posted on Mon, 04 Oct 2010 10:40:29 -0700 as excerpted:
On 10/04/2010 12:50 AM, Michael Haubenwallner wrote:
On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
[Portage is something] that I really need to rely on,
so whatever I do, I'll keep
On 05-10-2010 03:55, Diego Elio Pettenò wrote:
Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto:
That said, supporting this use case should not interfere with more
mainstream use of the distro. I like the USE flag proposal because it
lets us have our cake and eat it
Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
Like Richard said Gentoo is about choice...
By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software
house)
it can be its holly grail for
On 05-10-2010 12:03, Diego Elio Pettenò wrote:
Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
Like Richard said Gentoo is about choice...
By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire
Il giorno mar, 05/10/2010 alle 13.04 +0200, Angelo Arrifano ha scritto:
There are a lot of packages that need this information to correctly link
against libtool managed libraries, for example, there are packages that
linked against GL but didn't set -lGL -lGLU because it was relying on
libtool
Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha
scritto:
Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
and mesa did not use libtool for linking until very recently,
Actually, scratch that, mesa IS NOT USING LIBTOOL AT ALL.
So you hit the jackpot: you
I was just looking at some random ebuilds recently, and noticed this
snippet in gcc-4.5* ebuilds:
SSP_STABLE=amd64 x86 ppc ppc64 arm
# uclibc need tls and nptl support for SSP support
SSP_UCLIBC_STABLE=
Please note how the #-starting comment is inside the SSP_STABLE variable
declaration. It
On 10/05/2010 02:04 PM, Angelo Arrifano wrote:
You can extract from a .la things like the library name, version and
linking information (lib dependencies and paths). The information is
there and nothing prevented anyone from using it.
Can you provide any specific use case, or are you now
On 10/5/10 9:52 AM, Angelo Arrifano wrote:
By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software house)
it can be its holly grail for library versioning and linking. I don't
really feel like forcing users to change
On 05-10-2010 13:28, Diego Elio Pettenò wrote:
Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha
scritto:
Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
and mesa did not use libtool for linking until very recently,
Actually, scratch that, mesa IS NOT
Il giorno sab, 02/10/2010 alle 01.35 +, Robin H. Johnson ha scritto:
Which is a date of 2010/10/02, that just rolled up a few hours ago.
A constant value that was set 5 years ago come up :-).
All LDAP and the script are fixed now.
fl...@yamato rar % cvs up
Connection closed by
On 05-10-2010 13:49, Luca Barbato wrote:
On 10/5/10 9:52 AM, Angelo Arrifano wrote:
By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software house)
it can be its holly grail for library versioning and linking. I
$ euse --info system-sqlite
global use flags (searching: system-sqlite)
no matching entries found
local use flags (searching: system-sqlite)
[-] system-sqlite
On 15:52 Tue 05 Oct , Paweł Hajdan, Jr. wrote:
The meaning is identical in all those cases, and I think the number of
packages may have hit the threshold for a global flag.
However, we already have a very similar global USE flag: sqlite, which
makes this a bit more tricky. The
On Tue, Oct 5, 2010 at 7:41 PM, Donnie Berkholz dberkh...@gentoo.org wrote:
On 15:52 Tue 05 Oct , Paweł Hajdan, Jr. wrote:
The meaning is identical in all those cases, and I think the number of
packages may have hit the threshold for a global flag.
However, we already have a very similar
On Tue, 05 Oct 2010 13:49:43 +0200
Luca Barbato lu_z...@gentoo.org wrote:
Bluntly put, you seem to not know how libtool exactly works and
further down in the thread how linking exactly works. Please try to
learn the fine Gentoo docs on the subject and feel free to ask more
details on irc.
Ah,
On Tuesday 05 October 2010 18.52.29 Petteri Räty wrote:
On 10/05/2010 02:32 PM, Paweł Hajdan, Jr. wrote:
I was just looking at some random ebuilds recently, and noticed this
snippet in gcc-4.5* ebuilds:
SSP_STABLE=amd64 x86 ppc ppc64 arm
# uclibc need tls and nptl support for SSP
On 10/5/10 4:33 PM, Ciaran McCreesh wrote:
On Tue, 05 Oct 2010 13:49:43 +0200
Luca Barbatolu_z...@gentoo.org wrote:
Bluntly put, you seem to not know how libtool exactly works and
further down in the thread how linking exactly works. Please try to
learn the fine Gentoo docs on the subject and
On Tue, 05 Oct 2010 21:59:41 +0200
Luca Barbato lu_z...@gentoo.org wrote:
Great! It should be easy for you to fix it to only specify direct
link dependencies then, thus solving the underlying problem in one
place rather than working around it by fixing thousands of
individual packages.
RHJ == Robin H Johnson robb...@gentoo.org writes:
RHJ Some more issues for you:
RHJ 1. Increases the size of the Manifest by a minimum of 710 bytes _per_
RHJfile. (4 bytes for 'GPG ', 700-900 for the hash, 1 for the field space,
5-12 bytes for the
RHJtrailer).
RHJ 1.1. 55907 Manifest2
* Diego Elio Pettenò flamee...@gmail.com schrieb:
http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points
ACK.
IMHO, removing the .la files should be under invididual ebuild
(or eclass) control, and we also should try to get it fixed
at the source (if possible).
On 5 October 2010 23:38, Enrico Weigelt weig...@metux.de wrote:
And for Distros, it doesnt make sense to try to support anything imaginable.
Not breaking things that already work would be a decent compromise.
I'm now working in embedded area (where static linking is quite common)
for about
On Tue, Oct 05, 2010 at 05:53:50PM -0400, James Cloos wrote:
RHJ == Robin H Johnson robb...@gentoo.org writes:
RHJ Some more issues for you:
RHJ 1. Increases the size of the Manifest by a minimum of 710 bytes _per_
RHJfile. (4 bytes for 'GPG ', 700-900 for the hash, 1 for the field
On 10/05/2010 05:26 PM, Robin H. Johnson wrote:
On Tue, Oct 05, 2010 at 05:53:50PM -0400, James Cloos wrote:
Have portage note in the ebuild log what was signed, by what key, and
whether the sigs were true.
zmedico: can we include this in the repoman commit sig?
Sure. Currently, repoman only
On Tuesday, October 05, 2010 10:35:57 Nirbheek Chauhan wrote:
To fix this problem sqlite upstream made a specific change allowing a
#pragma to be used to define where secure-delete is required, avoiding
the need to use secure-delete *everywhere*.
so what you're saying is that this USE flag can
On Wed, Oct 6, 2010 at 7:36 AM, Mike Frysinger vap...@gentoo.org wrote:
On Tuesday, October 05, 2010 10:35:57 Nirbheek Chauhan wrote:
To fix this problem sqlite upstream made a specific change allowing a
#pragma to be used to define where secure-delete is required, avoiding
the need to use
We'll be unmasking GCC 4.5 soon. I was planning on this weekend but next
weekend is more likely. If you have open bugs on the tracker, please take a
look at them now.
https://bugs.gentoo.org/showdependencytree.cgi?id=296658hide_resolved=1
Thanks.
--
fonts, gcc-porting, we hold
28 matches
Mail list logo
