Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 266016 - >=dev-libs/libpcre-7.8-r1 does not provide static libs, lacks mechanism for linking against same
Summary: >=dev-libs/libpcre-7.8-r1 does not provide static libs, lacks mechanism for l...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords:
: 266689 266778 273783 274809 275053 280476 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-13 15:29 UTC by Mart Raudsepp
Modified: 2010-09-03 22:18 UTC (History)
18 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mart Raudsepp gentoo-dev 2009-04-13 15:29:37 UTC
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.
Comment 1 Dustin Howett 2009-04-13 15:55:12 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'
Comment 2 Peter Alfredsen (RETIRED) gentoo-dev 2009-04-13 16:05:35 UTC
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
Comment 3 Mart Raudsepp gentoo-dev 2009-04-13 16:12:52 UTC
Reopening for actual review. We are already aware that you deem this WONTFIX.
Comment 4 SpanKY gentoo-dev 2009-04-13 21:29:31 UTC
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.
Comment 5 Peter Alfredsen (RETIRED) gentoo-dev 2009-04-13 22:17:02 UTC
(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.

Comment 6 SpanKY gentoo-dev 2009-04-13 22:53:20 UTC
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.
Comment 7 Mark Loeser (RETIRED) gentoo-dev 2009-04-13 23:44:26 UTC
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
Comment 8 SpanKY gentoo-dev 2009-04-14 00:57:51 UTC
although, if libpcre does provide sane pkg-config files, we can push acceptance of that in face of .la files
Comment 9 Mart Raudsepp gentoo-dev 2009-04-16 01:52:49 UTC
Does that mean someone with the authority is going to revert this one individual package breakage anytime soon?
Comment 10 SpanKY gentoo-dev 2009-04-18 17:23:50 UTC
if no one gets around to it, i'll take care of it when i get back (again)
Comment 11 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2009-04-18 20:50:51 UTC
*** Bug 266689 has been marked as a duplicate of this bug. ***
Comment 12 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2009-04-18 20:55:50 UTC
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.
Comment 13 Peter Alfredsen (RETIRED) gentoo-dev 2009-04-18 21:20:48 UTC
+*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?
Comment 14 Mart Raudsepp gentoo-dev 2009-04-18 22:04:23 UTC
I believe comment #7 was referring to the .la files removal. Mark?
Comment 15 Mark Loeser (RETIRED) gentoo-dev 2009-04-19 17:06:43 UTC
(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.
Comment 16 Peter Alfredsen (RETIRED) gentoo-dev 2009-04-19 17:26:26 UTC
(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.
Comment 17 Gilles Dartiguelongue gentoo-dev 2009-04-19 22:59:36 UTC
*** Bug 266778 has been marked as a duplicate of this bug. ***
Comment 18 Kevin Bowling 2009-04-23 17:45:31 UTC
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 
Comment 19 Walter Meinl 2009-04-23 18:45:33 UTC
(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
Comment 20 Peter Alfredsen (RETIRED) gentoo-dev 2009-04-23 18:55:26 UTC
(In reply to comment #18)

Install dev-util/lafilefixer-0.5
run:
lafilefixer --justfixit
or
install gentoolkit
run:
revdep-rebuild -i -- -a

Comment 21 Walter Meinl 2009-04-23 19:15:06 UTC
(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
Comment 22 Timo Gurr (RETIRED) gentoo-dev 2009-06-10 14:47:38 UTC
*** Bug 273570 has been marked as a duplicate of this bug. ***
Comment 23 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2009-06-12 03:40:18 UTC
*** Bug 273783 has been marked as a duplicate of this bug. ***
Comment 24 Ortwin Glueck 2009-06-15 19:08:03 UTC
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).
Comment 25 Pacho Ramos gentoo-dev 2009-06-15 19:25:40 UTC
Did you run "lafilefixer --justfixit"? It worked fine for me in four different machines with x86 and amd64 arches
Comment 26 Ortwin Glueck 2009-06-17 12:10:43 UTC
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.
Comment 27 Ortwin Glueck 2009-06-17 19:00:34 UTC
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
Comment 28 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2009-06-21 06:06:44 UTC
*** Bug 274809 has been marked as a duplicate of this bug. ***
Comment 29 Timo Gurr (RETIRED) gentoo-dev 2009-06-22 14:08:29 UTC
*** Bug 275053 has been marked as a duplicate of this bug. ***
Comment 30 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2009-08-06 12:04:43 UTC
*** Bug 280476 has been marked as a duplicate of this bug. ***
Comment 31 Mark Loeser (RETIRED) gentoo-dev 2010-09-03 22:18:56 UTC
This seems to have reached a resolution.