[gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On 06/29/2012 04:30 PM, Thomas Sachau wrote: It is interesting, still you need a way to define HOST dependencies (stuff you need that has to be built on the host since you run it, e.g. xcb python code generator), something to play properly with ld and cross-vs-host paths for compilers (that part is _really_ annoying for qemu-chroots) lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On 06/30/2012 11:33 AM, Andreas K. Huettel wrote: > Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: >> On 06/30/2012 04:07 AM, Pacho Ramos wrote: >>> I would like to discuss a bit more issues like: >>> https://bugs.gentoo.org/show_bug.cgi?id=423087 >>> >>> Even if there are "a lot" of packages that can cause this breakage when >>> downgraded, I think it should be prevented and package managers >>> shouldn't try to downgrade this kind of packages as they will later >>> cause a total breakage. People is not supposed to know that downgrading >>> some package system will, for example, have an unusable gcc. >> >> It seems like a die in pkg_pretend would serve pretty well. > > As a comparatively simple, user-oriented workaround, since this only happens > at downgrades and these should be pretty rare, I have the following > suggestion: > > Make a portage feature that is **on by default**, which causes portage to > generate a binpkg of the version to be unmerged, in the case of a downgrade. > > Rationale: > * if you know what you are doing, you can switch this off easily > * does not take much space since downgrades are rare > * should help our users a lot, whenever someone accidentally or not-knowingly > downgrades something critical. > > Thoughts? I like that idea. I've filed this bug: https://bugs.gentoo.org/show_bug.cgi?id=424275 -- Thanks, Zac
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On 06/30/2012 12:42 PM, Ralph Sennhauser wrote: > That might be neat, but it would already help if you had to add > --allow-downgrades or similar to emerge in case Portage wants to > downgrade one or more packages. > Besides preventing an accidental downgrade it would raise the > awareness of the problem. I think people would just put it in EMERGE_DEFAULT_OPTS and forget about it, since downgrades are a fairly common occurrence, due to changes in version numbering schemes or buggy versions being dropped from the tree. Maybe a RESTRICT="downgrade" metadata setting would help to reduce the noise so that people would be less likely to enable --allow-downgrades by default. -- Thanks, Zac
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 20:33:35 +0200 "Andreas K. Huettel" wrote: > Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: > > On 06/30/2012 04:07 AM, Pacho Ramos wrote: > > > I would like to discuss a bit more issues like: > > > https://bugs.gentoo.org/show_bug.cgi?id=423087 > > > > > > Even if there are "a lot" of packages that can cause this > > > breakage when downgraded, I think it should be prevented and > > > package managers shouldn't try to downgrade this kind of packages > > > as they will later cause a total breakage. People is not supposed > > > to know that downgrading some package system will, for example, > > > have an unusable gcc. > > > > It seems like a die in pkg_pretend would serve pretty well. > > As a comparatively simple, user-oriented workaround, since this only > happens at downgrades and these should be pretty rare, I have the > following suggestion: > > Make a portage feature that is **on by default**, which causes > portage to generate a binpkg of the version to be unmerged, in the > case of a downgrade. > > Rationale: > * if you know what you are doing, you can switch this off easily > * does not take much space since downgrades are rare > * should help our users a lot, whenever someone accidentally or > not-knowingly downgrades something critical. > > Thoughts? > That might be neat, but it would already help if you had to add --allow-downgrades or similar to emerge in case Portage wants to downgrade one or more packages. Besides preventing an accidental downgrade it would raise the awareness of the problem. > Cheers, > Andreas > signature.asc Description: PGP signature
Re: [gentoo-dev] euscan GSoC project - requesting feedback
Am Mittwoch, 27. Juni 2012, 09:51:06 schrieb Federico "fox" Scrinzi: > The main question is: what would you like to have on this dashboard? Here's another suggestion for euscan: right now we already have rss feeds, but they are far too verbose for me and clutter up my news list. I dont really need an item whenever something enters portage How about a news feed that only contains "upstream" items? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: > On 06/30/2012 04:07 AM, Pacho Ramos wrote: > > I would like to discuss a bit more issues like: > > https://bugs.gentoo.org/show_bug.cgi?id=423087 > > > > Even if there are "a lot" of packages that can cause this breakage when > > downgraded, I think it should be prevented and package managers > > shouldn't try to downgrade this kind of packages as they will later > > cause a total breakage. People is not supposed to know that downgrading > > some package system will, for example, have an unusable gcc. > > It seems like a die in pkg_pretend would serve pretty well. As a comparatively simple, user-oriented workaround, since this only happens at downgrades and these should be pretty rare, I have the following suggestion: Make a portage feature that is **on by default**, which causes portage to generate a binpkg of the version to be unmerged, in the case of a downgrade. Rationale: * if you know what you are doing, you can switch this off easily * does not take much space since downgrades are rare * should help our users a lot, whenever someone accidentally or not-knowingly downgrades something critical. Thoughts? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
El sáb, 30-06-2012 a las 13:46 -0400, Ian Stakenvicius escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 30/06/12 01:30 PM, Pacho Ramos wrote:
> > El sáb, 30-06-2012 a las 13:17 -0400, Ian Stakenvicius escribió:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>
> >> On 30/06/12 11:16 AM, Mike Frysinger wrote:
> >>> On Saturday 30 June 2012 07:22:39 Zac Medico wrote:
> On 06/30/2012 04:07 AM, Pacho Ramos wrote:
> > I would like to discuss a bit more issues like:
> > https://bugs.gentoo.org/show_bug.cgi?id=423087
> >
> > Even if there are "a lot" of packages that can cause this
> > breakage when downgraded, I think it should be prevented
> > and package managers shouldn't try to downgrade this kind
> > of packages as they will later cause a total breakage.
> > People is not supposed to know that downgrading some
> > package system will, for example, have an unusable gcc.
>
> It seems like a die in pkg_pretend would serve pretty well.
> >>>
> >>> doing it on a per-ebuild basis doesn't make much sense. a
> >>> simple version compare (like we do in glibc as an exception to
> >>> this rule because of its much wider implication) is incorrect:
> >>> the new version might not introduce any new symbols compared to
> >>> the old one, and even if it has, other packages might not have
> >>> been linked against the new symbols. -mike
> >>
> >> Instead of preventing downgrade wouldn't it make more sense to
> >> figure out a way to force a rebuild on @system or @toolchain or
> >> whatever bits are broken as soon as the downgrade occurs, rather
> >> than just making it a one-way ticket? If we could sort this out
> >> (and sub-slots may help with this, but probably we'll need some
> >> extra work too) then we could probably support switching from
> >> ~arch to arch at a whim.. Not necessarily a bad goal.
> >>
> >
> > The problem is that, in this kind of breakage, gcc breaks as soon
> > as zlib is downgraded and, then, user cannot compile anything,
> > needing to manually find missing zlib lib from any other
> > distributions binaries, put it in the system and re-emerge zlib :|
> >
>
> ..but preserved-libs would keep that from happening wouldn't it? ie,
> the lib itself would stick around until gcc isn't using it anymore...
>
> so it'd just be a matter of an interim issue until preserved-libs is
> in stable portage ... and i'm guessing something that would suffice
> here is a blockage on downgrades of anything belonging to the contents
> of /var/db/edb/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED ?
>
> (apologies for the bad hack:)
>
> cat /var/db/pkg/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED \
> |sed -e 's#^/[^ ]* ##' |sed -e "s/,/\n/g" |sort -u \
> |xargs equery b |awk '{print $1}' |sort -u \
> |sed 's/^/
> ^^^ that's your build-preserving package.mask , yes?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iF4EAREIAAYFAk/vO4gACgkQ2ugaI38ACPBUvwEApQAljVOj492q2/bhttriqWgz
> iu8FZdsh1EHMeYaHxi0A/iZNY28W9NT5ynO6B42CAxpYpWym2SIc4JflTu/7IK1h
> =3pcd
> -END PGP SIGNATURE-
>
>
Looks like preserve-libs should be extended to handle this cases:
https://bugs.gentoo.org/show_bug.cgi?id=423087#c5
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/06/12 01:30 PM, Pacho Ramos wrote:
> El sáb, 30-06-2012 a las 13:17 -0400, Ian Stakenvicius escribió:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 30/06/12 11:16 AM, Mike Frysinger wrote:
>>> On Saturday 30 June 2012 07:22:39 Zac Medico wrote:
On 06/30/2012 04:07 AM, Pacho Ramos wrote:
> I would like to discuss a bit more issues like:
> https://bugs.gentoo.org/show_bug.cgi?id=423087
>
> Even if there are "a lot" of packages that can cause this
> breakage when downgraded, I think it should be prevented
> and package managers shouldn't try to downgrade this kind
> of packages as they will later cause a total breakage.
> People is not supposed to know that downgrading some
> package system will, for example, have an unusable gcc.
It seems like a die in pkg_pretend would serve pretty well.
>>>
>>> doing it on a per-ebuild basis doesn't make much sense. a
>>> simple version compare (like we do in glibc as an exception to
>>> this rule because of its much wider implication) is incorrect:
>>> the new version might not introduce any new symbols compared to
>>> the old one, and even if it has, other packages might not have
>>> been linked against the new symbols. -mike
>>
>> Instead of preventing downgrade wouldn't it make more sense to
>> figure out a way to force a rebuild on @system or @toolchain or
>> whatever bits are broken as soon as the downgrade occurs, rather
>> than just making it a one-way ticket? If we could sort this out
>> (and sub-slots may help with this, but probably we'll need some
>> extra work too) then we could probably support switching from
>> ~arch to arch at a whim.. Not necessarily a bad goal.
>>
>
> The problem is that, in this kind of breakage, gcc breaks as soon
> as zlib is downgraded and, then, user cannot compile anything,
> needing to manually find missing zlib lib from any other
> distributions binaries, put it in the system and re-emerge zlib :|
>
..but preserved-libs would keep that from happening wouldn't it? ie,
the lib itself would stick around until gcc isn't using it anymore...
so it'd just be a matter of an interim issue until preserved-libs is
in stable portage ... and i'm guessing something that would suffice
here is a blockage on downgrades of anything belonging to the contents
of /var/db/edb/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED ?
(apologies for the bad hack:)
cat /var/db/pkg/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED \
|sed -e 's#^/[^ ]* ##' |sed -e "s/,/\n/g" |sort -u \
|xargs equery b |awk '{print $1}' |sort -u \
|sed 's/^/
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
El sáb, 30-06-2012 a las 13:17 -0400, Ian Stakenvicius escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 30/06/12 11:16 AM, Mike Frysinger wrote: > > On Saturday 30 June 2012 07:22:39 Zac Medico wrote: > >> On 06/30/2012 04:07 AM, Pacho Ramos wrote: > >>> I would like to discuss a bit more issues like: > >>> https://bugs.gentoo.org/show_bug.cgi?id=423087 > >>> > >>> Even if there are "a lot" of packages that can cause this > >>> breakage when downgraded, I think it should be prevented and > >>> package managers shouldn't try to downgrade this kind of > >>> packages as they will later cause a total breakage. People is > >>> not supposed to know that downgrading some package system will, > >>> for example, have an unusable gcc. > >> > >> It seems like a die in pkg_pretend would serve pretty well. > > > > doing it on a per-ebuild basis doesn't make much sense. a simple > > version compare (like we do in glibc as an exception to this rule > > because of its much wider implication) is incorrect: the new > > version might not introduce any new symbols compared to the old > > one, and even if it has, other packages might not have been linked > > against the new symbols. -mike > > Instead of preventing downgrade wouldn't it make more sense to figure > out a way to force a rebuild on @system or @toolchain or whatever bits > are broken as soon as the downgrade occurs, rather than just making it > a one-way ticket? If we could sort this out (and sub-slots may help > with this, but probably we'll need some extra work too) then we could > probably support switching from ~arch to arch at a whim.. Not > necessarily a bad goal. > The problem is that, in this kind of breakage, gcc breaks as soon as zlib is downgraded and, then, user cannot compile anything, needing to manually find missing zlib lib from any other distributions binaries, put it in the system and re-emerge zlib :| signature.asc Description: This is a digitally signed message part
Re: GLEP draf for cross-compile support in multilib profiles (was: Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5))
On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau wrote: > I'm interested in this because I'm regularly annoyed with the emul- packages and also because multilib is pretty important for mips. > If a package has dependencies, then those dependencies are required to have > at least the same targets enabled as the package That seems like the obvious (but perhaps naive) choice. What about depending on packages that don't install libraries, like x11-proto/ packages or generators like dev-util/indent? Maybe I just don't understand. Would these packages even have ABI flags? It's clear to me that libraries would be installed in different lib* directories dependent on their ABI, but how would typical executables be handled? For mips, we'd like to have gcc built as an n64 binary, which would require its run-time dependencies (mpfr, mpc, gmp, etc.) to be available as n64 as well, but the rest of the system to be n32 binaries. Does this fit with your understanding (and proposed solution) of the problem? Thanks, Matt
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/12 11:16 AM, Mike Frysinger wrote: > On Saturday 30 June 2012 07:22:39 Zac Medico wrote: >> On 06/30/2012 04:07 AM, Pacho Ramos wrote: >>> I would like to discuss a bit more issues like: >>> https://bugs.gentoo.org/show_bug.cgi?id=423087 >>> >>> Even if there are "a lot" of packages that can cause this >>> breakage when downgraded, I think it should be prevented and >>> package managers shouldn't try to downgrade this kind of >>> packages as they will later cause a total breakage. People is >>> not supposed to know that downgrading some package system will, >>> for example, have an unusable gcc. >> >> It seems like a die in pkg_pretend would serve pretty well. > > doing it on a per-ebuild basis doesn't make much sense. a simple > version compare (like we do in glibc as an exception to this rule > because of its much wider implication) is incorrect: the new > version might not introduce any new symbols compared to the old > one, and even if it has, other packages might not have been linked > against the new symbols. -mike Instead of preventing downgrade wouldn't it make more sense to figure out a way to force a rebuild on @system or @toolchain or whatever bits are broken as soon as the downgrade occurs, rather than just making it a one-way ticket? If we could sort this out (and sub-slots may help with this, but probably we'll need some extra work too) then we could probably support switching from ~arch to arch at a whim.. Not necessarily a bad goal. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/vNKcACgkQ2ugaI38ACPDDgQD/XhgB1G6rIYXuhR/EnJDLyfgL NKfW6TifMcJr9wHFNooA/2RDkxOSFePAHy81IxGWfjvpb2wNw4b/IzDwK8u4hcAS =Q3Wd -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of perl modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/12 05:30 AM, Zac Medico wrote: > On 06/30/2012 01:46 AM, Torsten Veller wrote: >> * Ian Stakenvicius : >>> FYI, all the work subslotting the perl stuff doesn't work yet, >>> so it's probably best to wait a few days before trying it out. >> >> Perl modules have to be rebuilt if dev-lang/perl's useflags are >> changed. >> >> That would make dev-lang/perl's SLOT depend on users USE flags >> settings which is forbidden. Or will it work for sub-slot part? >> SLOT="0/5.16(?ithreads:-ithreads)(?debug:-debug)" > > Maybe this useflags synchronization thing is best managed with the > existing USE deps support? So, if something interacts with perls > ithreads and debug flags, its dependency should be something like > dev-lang/perl[ithreads=][debug=]. I think this makes a lot of sense too -- use-flag synchronization would probably be best handled outside of SLOT, otherwise we'd have to implement dynamic slots to get this properly supported. Now, that being said, it might be worthwhile if perl-module was expanded a bit in relation to the *DEPEND it adds -- having a PERL_MODULE_USES var or something, that could automatically append to IUSE (if necessary) and set the use-deps on dev-lang/perl, would make this a fairly simple implementation I think. Do all packages need to be rebuilt when some of these use flags change? Maybe auto-appending those particular flags (ithreads, debug) to IUSE and putting them on the dev-lang/perl dep is all that'll be needed, if this is the case. - - On an semi-related note, I have noticed that there are a fair number of ebuilds in the tree that are using perl-module at EAPI=4 and have 'perl? (dev-lang/perl)' in *DEPEND, but are not setting GENTOO_DEPEND_ON_PERL=no before their inherit (and so perl is ALWAYS a dep). I'm thinking of filing bugs against all of these... - - Finally, thanks for testing!! I hope to improve the overlay a bit by the middle of next week, including a script that'll patch /var/db/pkg to simulate 4-slot-abi always existing (so one doesn't have to emerge - -e @world to get their environment ready to test). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/vM28ACgkQ2ugaI38ACPAXlAD+KvzYGYMaTbgYS3eT6ADGzhEv 4+ehZ4PQ+9fNEyBMpn8A/2GXQqWY9erx+Dd8FL/jwk8KbReJoMwfffPEWCe38rfW =4DDP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: grub:2 keywords
On Sat, Jun 30, 2012 at 8:55 AM, Duncan <1i5t5.dun...@cox.net> wrote: > 3) For EFI-based GPT, there's another entirely separate special reserved > partition for the EFI system. An EFI partition can reside on a disk with an MBR (legacy) partitioning scheme, GPT scheme, El Torito CD-ROM boot entry, etc. For MBR, 0xEF partition ID is used, and the same platform ID is used in El Torito; GPT uses a corresponding GUID. > According to the EFI spec, this must be > formatted FAT32, No, the UEFI specification mandates that FAT12/16/32 EFI partitions must be supported, but allows the firmware to support other filesystems, with or without the 0xEF / GUID marker above. > and should be 256 MB or so. No such requirement. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Saturday 30 June 2012 07:22:39 Zac Medico wrote: > On 06/30/2012 04:07 AM, Pacho Ramos wrote: > > I would like to discuss a bit more issues like: > > https://bugs.gentoo.org/show_bug.cgi?id=423087 > > > > Even if there are "a lot" of packages that can cause this breakage when > > downgraded, I think it should be prevented and package managers > > shouldn't try to downgrade this kind of packages as they will later > > cause a total breakage. People is not supposed to know that downgrading > > some package system will, for example, have an unusable gcc. > > It seems like a die in pkg_pretend would serve pretty well. doing it on a per-ebuild basis doesn't make much sense. a simple version compare (like we do in glibc as an exception to this rule because of its much wider implication) is incorrect: the new version might not introduce any new symbols compared to the old one, and even if it has, other packages might not have been linked against the new symbols. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On 06/30/2012 04:07 AM, Pacho Ramos wrote: > I would like to discuss a bit more issues like: > https://bugs.gentoo.org/show_bug.cgi?id=423087 > > Even if there are "a lot" of packages that can cause this breakage when > downgraded, I think it should be prevented and package managers > shouldn't try to downgrade this kind of packages as they will later > cause a total breakage. People is not supposed to know that downgrading > some package system will, for example, have an unusable gcc. It seems like a die in pkg_pretend would serve pretty well. -- Thanks, Zac
[gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
I would like to discuss a bit more issues like: https://bugs.gentoo.org/show_bug.cgi?id=423087 Even if there are "a lot" of packages that can cause this breakage when downgraded, I think it should be prevented and package managers shouldn't try to downgrade this kind of packages as they will later cause a total breakage. People is not supposed to know that downgrading some package system will, for example, have an unusable gcc. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of perl modules
On 06/30/2012 01:46 AM, Torsten Veller wrote: > * Ian Stakenvicius : >> FYI, all the work subslotting the perl stuff doesn't work yet, so it's >> probably best to wait a few days before trying it out. > > Perl modules have to be rebuilt if dev-lang/perl's useflags are changed. > > That would make dev-lang/perl's SLOT depend on users USE flags settings which > is forbidden. Or will it work for sub-slot part? > SLOT="0/5.16(?ithreads:-ithreads)(?debug:-debug)" Maybe this useflags synchronization thing is best managed with the existing USE deps support? So, if something interacts with perls ithreads and debug flags, its dependency should be something like dev-lang/perl[ithreads=][debug=]. -- Thanks, Zac
[gentoo-dev] About forcing rebuilds of perl modules
* Ian Stakenvicius : > FYI, all the work subslotting the perl stuff doesn't work yet, so it's > probably best to wait a few days before trying it out. Perl modules have to be rebuilt if dev-lang/perl's useflags are changed. That would make dev-lang/perl's SLOT depend on users USE flags settings which is forbidden. Or will it work for sub-slot part? SLOT="0/5.16(?ithreads:-ithreads)(?debug:-debug)" -- Thanks Torsten
Re: [gentoo-dev] prune_libtool_files is NOT a direct replacement for, example, find "${D}" -name '*.la' -delete
On Thu, 28 Jun 2012 23:18:56 +0200 Pacho Ramos wrote: > El jue, 28-06-2012 a las 10:26 +0200, Michał Górny escribió: > > On Wed, 27 Jun 2012 22:12:34 +0300 > > Samuli Suominen wrote: > > > > > The logic in prune_libtool_files is not perfect[1]. > > > > Define 'perfect'. > > > > > To clarify: > > > > > > Use `prune_libtool_files --all` instead of plain > > > `prune_libtool_files` if you don't test the package with the USE > > > flags. > > > > Sounds like abuse of '--all' to me. It's like calling 'rm -r' for > > single file... > > > > > [1] http://bugs.gentoo.org/421197 > > > > But we will need to use "--all" in cases like pointed in that bug > report, no? :/ You need to use it if the package passes '-module' to libtool, and doesn't use plugin loader which uses .la files (ltdl, gmodule). The main point is that installing _those_ .la files doesn't do any harm to the system (they can't be linked against). Removing them may (for example, in ImageMagick). It's sad that people start running with pitchforks when they see anything looking like .la without really understanding what it does. And yes, I already had users removing all *.la files and then complaining programs no longer work... -- Best regards, Michał Górny signature.asc Description: PGP signature
