User account creation filtered due to spam.

Bug 29205 - lib/pkgconfig/libgcj.pc needs to become version dependent
Summary: lib/pkgconfig/libgcj.pc needs to become version dependent
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 4.1.0
: P3 major
Target Milestone: 4.2.0
Assignee: Tom Tromey
Depends on:
Blocks: 346
  Show dependency treegraph
Reported: 2006-09-24 17:26 UTC by Gerald Pfeifer
Modified: 2006-10-21 21:49 UTC (History)
4 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2006-10-10 17:19:10


Note You need to log in before you can comment on or make changes to this bug.
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

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
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

	PR libgcj/29205:
	* Rebuilt.
	* (install-data-local): Install the .pc file.
	(pkgconfig_DATA): Removed.


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.