Summary: | >=dev-libs/libpcre-7.8-r1 does not provide static libs, lacks mechanism for linking against same | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mart Raudsepp <leio> |
Component: | New packages | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Adrian.Bassett, alaricx, bugs+gentoo, caster, gengor, gentoo, hofmanj, hrubi, jer, kevin.bowling, loki_val, luke-jr+gentoobugs, mattsch, pacho, piorekf, proteuss, sebastian, wuno |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Mart Raudsepp
2009-04-13 15:29:37 UTC
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. |