Bug 29205

Summary: lib/pkgconfig/libgcj.pc needs to become version dependent
Product: gcc Reporter: Gerald Pfeifer <gerald>
Component: libgcjAssignee: Tom Tromey <tromey>
Status: RESOLVED FIXED    
Severity: major CC: gcc-bugs, java-prs, tromey, tromey
Priority: P3    
Version: 4.1.0   
Target Milestone: 4.2.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2006-10-10 17:19:10
Bug Depends on:    
Bug Blocks: 346    

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.