dev-libs/libpcre-7.8-r1 and forward has the following significant changes done to it: * Disables shipping of static libraries unconditionally * Unconditionally removes all *.la files While the first can be quite a problem for users wanting to link libpcre statically to their own programs they develop and want to ship binaries with libpcre linked in statically (it is BSD licensed afterall), the big problem is with the latter. Removing *.la files starting at lower level libraries simply does not work and must be avoided until at least there is a global plan in place regarding it. It basically breaks the building of all packages using libpcre indirectly until everything in that indirect chain is rebuilt to tweak the higher level libraries *.la files for the change. Also, I strongly believe the correct fix lays within libtool itself - working with upstream to fix the issues relating to the *.la files themselves. * Differentiate between direct and indirect dependencies. * Don't bother looking up libtool files of indirect dependencies on shared library handling case, at least on ELF systems * In general work better in regards to direct vs indirect deps and don't penalize ELF systems so badly So this libtool change should be reverted from this package, that is needed by even system packages, to minimize the pain that is going to cause to users and not done anywhere before a project-wide plan is in place, or libtool is made nicer for this. Individual developers taking this example of *.la files killing and applying as well will quickly spiral into users having to run revdep-rebuild to rebuild a large set of their packages (possibly multiple times for one case to get it truly fixed) over and over again for each incident. Additionally there can be additional issues when the *.la files would be reintroduced later on, especially if this change trickles down to stable tree. I am CCing QA right away because the maintainer has already stated that escalation is necessary, because he refuses to revert this.
This also appears to cause issues linking libpcre++ using libtool. /bin/sh ../../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -I../../.. -I../../../src -DPALUDIS_HAVE_EXTERN_TEMPLATE=1 -pthread -Wall -Wextra -Wold-style-cast -Wredundant-decls -Wstrict-null-sentinel -Wmissing-noreturn -Woverloaded-virtual -Winit-self -Wunused -Wunused-function -Wshadow -Wwrite-strings -Wfloat-equal -O2 -pipe -msse3 -march=athlon64 -Wl,-O1 -o man-inquisitio man_inquisitio.o command_line.o ../../../paludis/args/libpaludisargs_0.36.la ../../../paludis/args/libpaludisman_0.36.a ../../../paludis/util/libpaludisutil_0.36.la ../../../paludis/libpaludismanpagethings_0.36.la ../../../src/output/liboutput.a -ldl -L/usr/lib64 -lpcre++ mkdir .libs libtool: link: cannot find the library `/usr/lib64/libpcre.la' or unhandled argument `/usr/lib64/libpcre.la'
I will not fix this. Reporter promised a fix for the libtool files problem on gentoo-dev@g.o within a month in December. No such fix has been forthcoming. In fact, all the reporter has done has been to criticise the solution of removing the .la files while not doing anything to fix the problems associated with .la files, such as the libxcb problems which will soon hit the tree with version 1.2. I removed the .la files from libpcre because: 1) If glib is to sometime depend on it in the future, even if there should be a .so bump, removing the .la files from libpcre will impact on the order of 400 packages on a regular Gnome/XFCE desktop. I had 3 packages to rebuild with the current fix on a Gnome desktop. People with kde-3.5 have reported 30. 2) Libtool files are no longer needed since the .a archive was also removed. 3) I also note that it is the policy of several other distros to remove .la files. Debian, for instance, does not ship .la files for pcre3 As the maintainer of said package I think the fact that I had in fact considered the consequences of my actions and that I have made a reasonable cost-benefit assesment and that I am responsive to dialogue should prejudice any decision in my favor unless the damage is immediate and system-breaking. Otherwise I wonder what other changes QA will have to rule upon. Do you really want to have to second-guess every maintainer-decision every time it means revdep-rebuild has to be run? Or just every time Reporter sees a change that he doesn't like? For anyone running across this issue, running: revdep-rebuild -i -- -a will fix your problem. Marking WONTFIX
Reopening for actual review. We are already aware that you deem this WONTFIX.
removing of .la files is one thing, but no one said you could remove .a files. specific Gentoo policy is to install those all the time. otherwise you just broke people trying to link statically against libpcre without any way of recovering. and if the .la files are still required due to the .a files, well then i guess you dont have much choice on that front either.
(In reply to comment #4) > removing of .la files is one thing, but no one said you could remove .a files. > specific Gentoo policy is to install those all the time. That is not the case. See discussion on gentoo-dev@g.o: "[gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal" Where it was basically agreed (also on IRC) to only install them where needed. I know Gnome Herd is going with plans to disable static libraries also. (Unless that has changed?) > otherwise you just > broke people trying to link statically against libpcre without any way of > recovering. All in-tree cases have been fixed (grep). If anyone needs the static libs for anything else, the ebuild does obey EXTRA_ECONF. > and if the .la files are still required due to the .a files, well > then i guess you dont have much choice on that front either. The .a files aren't required. The .la files aren't required.
the static-libs hasnt moved forward which means it is still policy to install the files. you've even ignored it: libpcre doesnt have a conditional static flag, it hard codes --disable-static. EXTRA_ECONF is not a solution. that means .a files are required. also, i dont think you can make the .la file install conditional. if you build libpcre with static support, the .la files are required to properly statically link against pcre. then any other package that compiles against libpcre will now use the .la file. but if libpcre is built w/out the static libs, the .la files cannot go away as other things may still refer to it.
Please revert this until there is an actual decision made by the council. This is changing existing policy, so it should be done by them, and should be properly documented so we know why we are doing things a certain way. Thanks, Mark
although, if libpcre does provide sane pkg-config files, we can push acceptance of that in face of .la files
Does that mean someone with the authority is going to revert this one individual package breakage anytime soon?
if no one gets around to it, i'll take care of it when i get back (again)
*** Bug 266689 has been marked as a duplicate of this bug. ***
This seems to have been fixed already. from ChangeLog: *libpcre-7.9 (12 Apr 2009) 12 Apr 2009; Peter Alfredsen <loki_val@gentoo.org> -libpcre-7.9_rc2.ebuild, +libpcre-7.9.ebuild: Bump 12 Apr 2009; Peter Alfredsen <loki_val@gentoo.org> libpcre-7.8-r1.ebuild, libpcre-7.9_rc2.ebuild: Use gen_usr_ldscript instead of clunky symlinks handling. Thanks to grobian.
+*libpcre-7.9-r1 (18 Apr 2009) +*libpcre-7.8-r2 (18 Apr 2009) + + 18 Apr 2009; Peter Alfredsen <loki_val@gentoo.org> + -files/libpcre-7.7-buffer-overflow.patch, + +files/libpcre-7.9-pkg-config.patch, -libpcre-7.8-r1.ebuild, + +libpcre-7.8-r2.ebuild, -libpcre-7.9.ebuild, +libpcre-7.9-r1.ebuild: + Provide static libraries per bug 266016. Provide pkg-config file to link + statically against libpcreposix as replacement for .la files. Remove old + patch file. + Now that all concerns raised by people who did not promise to "hunt me down" have been fixed, can we please get back to doing our job?
I believe comment #7 was referring to the .la files removal. Mark?
(In reply to comment #14) > I believe comment #7 was referring to the .la files removal. Mark? > It was referring to everything that was changed. I believe Mike said it best in comment #8 though. If there is a mechanism that works, we can use that.
(In reply to comment #15) > It was referring to everything that was changed. I believe Mike said it best > in comment #8 though. If there is a mechanism that works, we can use that. There is now. dev-util/lafilefixer will fix your .la's and the pkg-config files will work for static linking. Bug fixed.
*** Bug 266778 has been marked as a duplicate of this bug. ***
Is anyone else hitting this bug with 'dev-libs/redland'? /bin/sed: can't read /usr/lib64/libpcre.la: No such file or directory libtool: link: `/usr/lib64/libpcre.la' is not a valid libtool archive
(In reply to comment #18) > Is anyone else hitting this bug with 'dev-libs/redland'? > > /bin/sed: can't read /usr/lib64/libpcre.la: No such file or directory > libtool: link: `/usr/lib64/libpcre.la' is not a valid libtool archive > yes, exactly the same here
(In reply to comment #18) Install dev-util/lafilefixer-0.5 run: lafilefixer --justfixit or install gentoolkit run: revdep-rebuild -i -- -a
(In reply to comment #20) > (In reply to comment #18) > revdep-rebuild -i -- -a > That did the trick see also bug266778, sorry for the spam
*** Bug 273570 has been marked as a duplicate of this bug. ***
*** Bug 273783 has been marked as a duplicate of this bug. ***
Oh glory, the package has hit stable and now us poor users are bleeding badly. What do we care about installing .la or not when it just prevents us from emerging packages? I though portage was about automatically RESOLVING dependencies, not creating problems with them. Now we have to care about FIXING things that portage BROKE? I don't like where this is way leading. PLEASE make installing packages EASY again (no bloody fixthisandthat).
Did you run "lafilefixer --justfixit"? It worked fine for me in four different machines with x86 and amd64 arches
Pacho, the problem is not that lafilefixer wouldn't work. It does. The problem is that this is an addional step required after the installation in order to install ANY other dependent package. My point is, that a libpcre install is completely useless to users without the .la files. So they should be installed by default. Currently everyone has to pay the price just because a handful of people don't want .la files. That's nuts.
Ok, I understand now that it's not libpcre's fault that .la files of other packages wrongly depend on its .la file. And that lafilefixer fixes those broken .la files. Fair enough. See http://blog.flameeyes.eu/2009/04/18/some-details-about-our-old-friends-the-la-files
*** Bug 274809 has been marked as a duplicate of this bug. ***
*** Bug 275053 has been marked as a duplicate of this bug. ***
*** Bug 280476 has been marked as a duplicate of this bug. ***
This seems to have reached a resolution.
