/usr/lib/classpath/libgjsmalsa.la /usr/lib/classpath/libgjsmalsa.so are installed by both dev-java/gnu-classpath and by >=sys-devel/gcc-4.1.0 Not sure what to suggest, here. Perhaps gcc could RDEPEND on gnu-classpath, and gcc could remove /usr/lib/classpath/libgjsmalsa.so from gcc's image directory.
I don't think you could just depend on classpath. If I understand it correctly, gcj uses a bundled version of classpath which is a bit different than a stock classpath.
I was going to ask on the gcc mailing list, but then saw the following at http://www.gnu.org/software/classpath/announce/20060515.html: "The GNU Classpath developer snapshot releases are not directly aimed at the end user but are meant to be integrated into larger development platforms. For example the GCC (gcj) and Kaffe projects will use the developer snapshots as a base for future versions. More projects based on GNU Classpath: http://www.gnu.org/software/classpath/stories.html" which implies we shouldn't be providing a gnu-classpath package, and that all apps that use it shuold have it bundled. Potentially this will create collisions across all packages with bundled gnu-classpath, which is a pita. However the reality is that gcc basically builds libgcj for itself, which is fine because that doesn't conflict with classpath. libgjsmalsa is the JNI MIDI-ALSA library, and the one supplied in gcc-4.1.1 is identical to that in gnu-classpath-0.90. I've asked on the gcc mailing list why they install libgjsmalsa to /usr/lib/classpath instead of /usr/lib/gcc/<target>/<version>.
Just a quick note - a response on the GCC mailing list indicates the colliding files have been moved in 4.2.
*** This bug has been marked as a duplicate of 135840 ***
