Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
Le mercredi 12 novembre 2008 à 18:16 +0100, Peter Alfredsen a écrit : [snip] > > Mart had already proposed a "static-lib" USE flag. Donnie just > > suggested on IRC we turn this use flag into a FEATURES flag. > > That's problematic. You can't turn off a FEATURES flag for individual > packages. See above. yes you can, can't find the related doc (it's not in portage man), but that's what /etc/portage/env/ can do for you. -- Gilles Dartiguelongue <[EMAIL PROTECTED]>
[gentoo-dev] Re: An official Gentoo wiki
Tobias Scherbaum <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 13 Nov 2008 18:21:38 +0100: > Wikipedia started using an extension for marking pages as "validated". > See [1]. This would allow us to setup a group of "trusted people" > (developers, long-time users, well-known contributors - for example) who > would be able to review pages and tag them that way. Non-reviewed pages > could show a header then clearly stating that this specific page hasn't > been reviewed and might contain inaccurate information. That sounds like a useful idea. They make it the default view. I think I'd prefer a more normal HEAD view, but with a notation at the top similar to: "This wiki page as it appeared on was validated. Show me the validated version." -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Wed, 12 Nov 2008 18:31:47 +0100 Peter Alfredsen <[EMAIL PROTECTED]> wrote: > On Wednesday 12 November 2008, Mart Raudsepp wrote: > > There is still no solution for things that do not break ABI, but get > > rebuilt with different USE flags, for example the USE=esd fiasco > > where to get rid of esound you had to remove USE=esd and rebuild > > many packages with revdep-rebuild for no reason other than libtool > > being stupid. This stupidity should be fixed, not delayed with > > workarounds to a small subset of cases. > > I disagree. Just because you can have a feast tomorrow doesn't mean > that you should abstain from eating today. Well, you won't make it to the feast if you're stuck at the dam, plugging all the holes with your fingers. > > > We talked about this on #gentoo-dev the other day. 200 packages > > > out of 1000 on my system had to be rebuilt because of this. If > > > libxcb didn't use la files, that wouldn't have been necessary for > > > the majority of those. If the packages themselves didn't use la > > > files, it wouldn't have been necessary either. > > > > Or if libtool would be fixed to not cause that pain in the first > > place.. > > That would indeed be nice. Please convince me that you can implement > an upstreamable solution within 2 months time and I won't be needing > this function. > > [Snip more pie-in-the-sky] > > Show me the code, please. If you weren't interested in hearing differing opinions, then why did you ask in the first place? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] [RFC] simple-build eclass
I've already written about the possibility of creating an ebuild to
simply _replace_ the entire buildsystem of a package if it's
non-existant (simple .c file thrown around by upstream), too minimal
and/or impossible to get upstream do adapt, or as a temporary measure
until upstream is beaten into common sense.
The whole story can be found at
http://blog.flameeyes.eu/2008/10/15/fixing-cflags-ldflags-handling-with-a-single-boilerplate-makefile
I'm attaching a proof of concept of the eclass, it's certainly not ready
for prime time: it does not support C++ programs, it does not have
pkg-config support, and so on. But in general it should work, I'm also
attaching a reworked ebuild for uif2iso (package I maintain and for
which I had to _rewrite_ the whole Makefile already).
This gets especially interesting to consider if we want to enable
--as-needed by default, since this will allow easy fix for packages that
don't otherwise build with --as-needed, like habak that I had to fix,
and takes care of quite a few different problems at once.
HTH,
# Copyright 2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Author: Diego Pettenò <[EMAIL PROTECTED]>
inherit toolchain-funcs
EXPORT_FUNCTIONS src_compile src_install
simple-build_src_compile() {
cat - > Makefile <# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit simple-build flag-o-matic
DESCRIPTION="Converts MagicISO CD-images to iso"
HOMEPAGE="http://aluigi.org/mytoolz.htm#uif2iso";
SRC_URI="mirror://gentoo/${P}.zip"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""
RDEPEND="sys-libs/zlib"
DEPEND="${RDEPEND}
app-arch/unzip"
SIMPLE_SOURCES='src/*.c'
SIMPLE_LIBRARIES='-lz'
src_compile() {
append-flags -DMAGICISO_IS_SHIT
simple-build_src_compile
}
src_install() {
simple-build_src_install
dodoc "${WORKDIR}"/${PN}.txt "${WORKDIR}"/README || die "dodoc failed"
}
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
pgp7HRsrICOry.pgp
Description: PGP signature
[gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Wed, 12 Nov 2008 18:31:47 +0100 Peter Alfredsen <[EMAIL PROTECTED]> wrote: > On Wednesday 12 November 2008, Mart Raudsepp wrote: > > There is still no solution for things that do not break ABI, but get > > rebuilt with different USE flags, for example the USE=esd fiasco > > where to get rid of esound you had to remove USE=esd and rebuild > > many packages with revdep-rebuild for no reason other than libtool > > being stupid. This stupidity should be fixed, not delayed with > > workarounds to a small subset of cases. > > I disagree. Just because you can have a feast tomorrow doesn't mean > that you should abstain from eating today. Well, you won't make it to the feast if you're stuck at the dam, plugging all the holes with your fingers. > > > We talked about this on #gentoo-dev the other day. 200 packages > > > out of 1000 on my system had to be rebuilt because of this. If > > > libxcb didn't use la files, that wouldn't have been necessary for > > > the majority of those. If the packages themselves didn't use la > > > files, it wouldn't have been necessary either. > > > > Or if libtool would be fixed to not cause that pain in the first > > place.. > > That would indeed be nice. Please convince me that you can implement > an upstreamable solution within 2 months time and I won't be needing > this function. > > [Snip more pie-in-the-sky] > > Show me the code, please. If you weren't interested in hearing differing opinions, then why did you ask in the first place? :P -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
Hi, > (I think pulseaudio is fixed, actually.) For what it's worth: removing the .la files from pulseaudio breaks its module loading on freebsd; and it's an elf system. I don't know what you mean by fixed and I didn't investigate this but restoring the .la files in the ebuild allowed me to make it load its plugins. Maybe that's another issue or maybe there's something we have forgotten about the .la files; I think pulseaudio uses libltdl and iirc these was a case where the .la files were needed at runtime. Imho, the only option for punting .la files are the ones that are opt-in, opt-out ones should be discarded. Having it as a feature is opt-out and will break anything that needs it and doesn't have the restrict yet. On the other hand, maybe this could be some property like "la_files_can_be_punted" which is, as i understand it, the opt-in version of restrict. Moreover .la files are good when you want to link statically to some library because they carry the needed information; they should be punted only when said library provides a good alternative (like a .pc file with correct libs.private field). Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
Alexis Ballier a écrit : > Hi, > >> (I think pulseaudio is fixed, actually.) > > For what it's worth: removing the .la files from pulseaudio breaks its > module loading on freebsd; and it's an elf system. I don't know what > you mean by fixed It's not fixed and it can't be. libtool's cross-platform dlopen() wrapper library (libltdl) needs .la files even on ELF systems. The only way to fix this is to use dlopen() instead... Cheers Rémi
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Fri, 14 Nov 2008 11:35:44 +0100 Gilles Dartiguelongue <[EMAIL PROTECTED]> wrote: > Le mercredi 12 novembre 2008 à 18:16 +0100, Peter Alfredsen a écrit : > [snip] > > > Mart had already proposed a "static-lib" USE flag. Donnie just > > > suggested on IRC we turn this use flag into a FEATURES flag. > > > > That's problematic. You can't turn off a FEATURES flag for > > individual packages. See above. > > yes you can, can't find the related doc (it's not in portage man), but > that's what /etc/portage/env/ can do for you. Only for some FEATURES though (depending on where they are implemented).
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On 15:25 Fri 14 Nov , Alexis Ballier wrote: > Moreover .la files are good when you want to link statically to some > library because they carry the needed information; they should be > punted only when said library provides a good alternative (like a .pc > file with correct libs.private field). Perhaps writing a .la to .pc converter would be a worthwhile endeavor. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpLDuhbD3onh.pgp Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Fri, 14 Nov 2008 14:31:56 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 15:25 Fri 14 Nov , Alexis Ballier wrote: > > Moreover .la files are good when you want to link statically to some > > library because they carry the needed information; they should be > > punted only when said library provides a good alternative (like > > a .pc file with correct libs.private field). > > Perhaps writing a .la to .pc converter would be a worthwhile endeavor. One of these things is not like the other. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Friday 14 November 2008 14:25:30 Alexis Ballier wrote: > Moreover .la files are good when you want to link statically to some > library because they carry the needed information; they should be > punted only when said library provides a good alternative (like a .pc > file with correct libs.private field). Even if the .pc file exists and is fully correct, removing the .la file still breaks any application that links statically and relies on libtool to deal with library dependencies, rather than using pkg-config (and there's no reason why an application /shouldn't/ do that - after all, it works perfectly with the library as upstream released it). Maybe we think it's worth the effort to tweak the application's build system (there probably won't be all that many applications that need it, after all), but this /is/ an incompatible change to the library, and if we're going to do it, we should at least be aware of what we're doing.
Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Friday 14 November 2008, Ryan Hill wrote: > > [Snip more pie-in-the-sky] > > > > Show me the code, please. > > If you weren't interested in hearing differing opinions, then why did > you ask in the first place? :P I just thought it sounded like a tall order, saying that fixing libtool .la files would take some weekends to do, when this problem has existed for so long, yet noone has been able to fix it in a way that causes less pain than removal of all .la files does. IOW, I will believe promises of code when I see it. I won't be touching libtool. You can break that thing by just looking at it the wrong way. It'll eval your buttocks off and expr your behind, it's .3 MB of all posix-sh and it will make you regret you ever tried to wrap your head around it. [in re pulseaudio, I believed the news for 0.9.1 http://www.pulseaudio.org/wiki/OldNews] [Responding to the rest of the thread] I've given this some thought and I think I've been convinced that dberkholz' position is probably the most tenable. If this is to be done, we should do it in a documented "Gentooish" way. The problem with going down the FEATURES road are two-fold: 1) What should the behavior of the FEATURES flag be? I think it should act like an INSTALL_MASK="*.la" and EXTRA_ECONF="--disable-static" There should also be a function, let's call it "exemptthis.la" that would exempt a .la file from being punted, so the RESTRICT could be made on a per-la file basis. 2) Who implements in portage? [...I know nothing of portage internals...] 3) Grunt work? This should be rather easy. Just assign the bugs to me and I shall add RESTRICTs as-needed. But the problem is that we've known about this for aeons and nothing has been done about it. Diego tried to do something with popt and another package some time ago (bug 218286) but he was mostly shouted down and nobody touched it since. On .so bumps I've silently dropped .la files, which I think is the more gradualistic approach and it also has the advantage of causing only little or no (extra) breakage, but for the whole tree it could take decades, since some libs don't do .so bumps. Anyway, we really need to start punting .la files one way or the other. For desktop users of our distro, they do a lot more harm than good. For embedded, perhaps static linking serves some purpose, but really, if you can't afford dynamic linking, what are you going to run on your board? -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Sat, 15 Nov 2008 00:05:52 +0100 Peter Alfredsen <[EMAIL PROTECTED]> wrote: > I just thought it sounded like a tall order, saying that fixing > libtool .la files would take some weekends to do, when this problem > has existed for so long, yet noone has been able to fix it in a way > that causes less pain than removal of all .la files does. Sometimes, doing nothing is better than doing something. > Anyway, we really need to start punting .la files one way or the > other. For desktop users of our distro, they do a lot more harm than > good. For embedded, perhaps static linking serves some purpose, but > really, if you can't afford dynamic linking, what are you going to > run on your board? No, for desktop users they're occasionally a minor inconvenience, which is more than offset by the large inconvenience of their removal. Unfortunately, enough fuss has been made about this that too many people will look bad if it's decided to do nothing, so things have reached the "find the least bad something to do" stage... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Sat, 2008-11-15 at 00:05 +0100, Peter Alfredsen wrote: > Anyway, we really need to start punting .la files one way or the other. > For desktop users of our distro, they do a lot more harm than good. For > embedded, perhaps static linking serves some purpose, but really, if > you can't afford dynamic linking, what are you going to run on your > board? Just to quickly explain the purpose of static linking on embedded - it has nothing to do with avoiding dynamic linking (run-time?) cost, it has everything to do with size. If you have a library that only one or few applications use, you can end up with smaller size through static linking it, rather than using a shared library of it. This is because during static linking all functions that are not used can be discarded from the final binary, while with shared libraries all the code has to remain, because it isn't know what will be using that shared library, so the toolchain can not safely discard anything, even if you just have one application using some big library, but only using a small subset of its functionality. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
Mart Raudsepp <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 15 Nov 2008 02:26:52 +0200: > This is because during > static linking all functions that are not used can be discarded from the > final binary, while with shared libraries all the code has to remain, > because it isn't know what will be using that shared library That was a very useful explanation. Thanks! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
