|Summary:||lib/pkgconfig/libgcj.pc needs to become version dependent|
|Product:||gcc||Reporter:||Gerald Pfeifer <gerald>|
|Component:||libgcj||Assignee:||Tom Tromey <tromey>|
|Severity:||major||CC:||gcc-bugs, java-prs, tromey, tromey|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2006-10-10 17:19:10|
|Bug Depends on:|
Description Gerald Pfeifer 2006-09-24 17:26:47 UTC
Currently, when installing two versions/copies of GCC into the same prefix, using suitable --libdir, --infodir and --program-suffix options, the *only* conflict, that is, the only file the second copy of GCC will overwrite, is lib/pkgconfig/libgcj.pc. One approach would be putting this into a version-specific subdirecty, such as --libdir, or name the file libgcj41.pc, libgcj42.pc, etc.
Comment 1 Tom Tromey 2006-10-02 17:51:47 UTC
I suspect we should put the version number, or at least major.minor, into the name. So, libgcj-4.1.pc, libgcj-4.2.pc, etc. What do you think of this?
Comment 2 Gerald Pfeifer 2006-10-09 19:46:02 UTC
Making the major.minor number (4.1, 4.2,...) part of the name sounds quite fine to me! (Sorry for the delay in responding to your question, Tom. I've been out last week.)
Comment 3 Tom Tromey 2006-10-10 17:19:09 UTC
Testing a patch.
Comment 4 Tom Tromey 2006-10-10 18:44:19 UTC
Subject: Bug 29205 Author: tromey Date: Tue Oct 10 18:44:06 2006 New Revision: 117610 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117610 Log: PR libgcj/29205: * Makefile.in: Rebuilt. * Makefile.am (install-data-local): Install the .pc file. (pkgconfig_DATA): Removed. Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in
Comment 5 Tom Tromey 2006-10-10 18:45:06 UTC
I've checked in the fix on the trunk. Do we need this in 4.1? I assume not on the theory that now the file names won't clash...
Comment 6 Gerald Pfeifer 2006-10-21 11:28:39 UTC
Thanks, Tom! I updated some packages I maintain and verified that this indeed nicely fixes the problem. As for GCC 4.1, as you say, I don't think it's strictly needed, though it could be useful for some (using GCC 4.0 and GCC 4.1 in parallel for example). Your call, I'd say. In any case, thanks a lot for tackling this problem!
Comment 7 Tom Tromey 2006-10-21 21:49:05 UTC
I'm going to close this as fixed. Thanks Gerald.