231314 2008-07-09 17:24 0000 sci-physics/geant-4.9.1_p02 doesn't install global libraries 2008-09-23 11:40:08 0000 1 1 1 Unclassified Gentoo Linux Library unspecified All Linux RESOLVED TEST-REQUEST P2 major --- 1 benni@netronaut.de sci-physics@gentoo.org fmccor@gentoo.org sci-physics@gentoo.org benni@netronaut.de 2008-07-09 17:24:38 0000 Hi, due to an incomplete sed of the Makefiles, the geant-4.9.1_p02 ebuild does build the "global libraries", but they are never merged since the ebuild does not find them. Also, with the current ebuild logic, it is impossible to build static global libraries. Patch follows. Cheers, Benjamin Reproducible: Always benni@netronaut.de 2008-07-09 17:27:21 0000 Created an attachment (id=159961) Fix global libs issues Changes are: * Call order for compile: Make sure env var for global is set before we try to build static objs, so get a chance to build static global libs. * sed to put global libraries in common TMP dir during compile bicatali@gentoo.org 2008-07-10 10:22:33 0000 In cvs. Thanks a lot! benni@netronaut.de 2008-07-16 20:11:07 0000 Created an attachment (id=160601) patch against version in portage v1.5 "make global" removes all the granular libraries we built in the step before. I had a look at the build process in the ./Configure script (install.sh): they build global first and then the rest. However, trying this order in the ebuild does not build the granular libraries ("no rule for obj.last" in "make global"). This patch just makes sure that the granular libraries are rebuild from the object files that are still around in case we build global libraries, too. benni@netronaut.de 2008-07-16 20:12:39 0000 The current ebuild version for USE=global removes the needed granular libs. Patch is in https://bugs.gentoo.org/attachment.cgi?id=160601 above. Sorry, b. fmccor@gentoo.org 2008-07-17 14:03:55 0000 This probably explains that no matter what I do, I can't build any of the examples. Closest I can get results in a huge number of things like: /usr/lib/geant4/libG4modeling.so: undefined reference to `CLHEP::HepRotation::thetaY() const' and the GNUmakefiles for the examples essentially don't (make anything) without a lot of help. bicatali@gentoo.org 2008-07-17 14:12:20 0000 OK, I applied the new patch in cvs. Thanks Benjamin. I'm leaving this bug open for more testing period. fmccor@gentoo.org 2008-07-17 16:17:22 0000 (In reply to comment #5) > This probably explains that no matter what I do, I can't build any of the > examples. Closest I can get results in a huge number of things like: > > /usr/lib/geant4/libG4modeling.so: undefined reference to > `CLHEP::HepRotation::thetaY() const' > > and the GNUmakefiles for the examples essentially don't (make anything) without > a lot of help. > It's more than just that for me, I guess. Several libraries for geant have this: U _ZN5CLHEP7HepZHatE resulting in: /usr/lib/geant4/libG4brep.so: undefined reference to `CLHEP::HepZHat' but nowhere in geant is defined any sort of symbol with 'Hat' in it. Although lots of _ZN5CLHEP symbols are defined, these aren't. fmccor@gentoo.org 2008-07-17 16:30:01 0000 (In reply to comment #7) > (In reply to comment #5) > > This probably explains that no matter what I do, I can't build any of the > > examples. Closest I can get results in a huge number of things like: > > > > /usr/lib/geant4/libG4modeling.so: undefined reference to > > `CLHEP::HepRotation::thetaY() const' > > > > and the GNUmakefiles for the examples essentially don't (make anything) without > > a lot of help. > > > > It's more than just that for me, I guess. Several libraries for geant have > this: > U _ZN5CLHEP7HepZHatE > > resulting in: > /usr/lib/geant4/libG4brep.so: undefined reference to `CLHEP::HepZHat' > > but nowhere in geant is defined any sort of symbol with 'Hat' in it. Although > lots of _ZN5CLHEP symbols are defined, these aren't. > My mistake. The're in libCLHEP, a separate package. benni@netronaut.de 2008-07-17 16:43:02 0000 (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > It's more than just that for me, I guess. Several libraries for geant have > > this: > > U _ZN5CLHEP7HepZHatE > > > > resulting in: > > /usr/lib/geant4/libG4brep.so: undefined reference to `CLHEP::HepZHat' > > > > but nowhere in geant is defined any sort of symbol with 'Hat' in it. Although > > lots of _ZN5CLHEP symbols are defined, these aren't. > > > > My mistake. The're in libCLHEP, a separate package. The geant4 Makefiles assume these libraries from sci-physics/clhep are in /usr/lib. I have no idea about sparc layout, but could it be that you CLHEP libraries are somewhere else? fmccor@gentoo.org 2008-07-17 17:40:05 0000 (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #5) > > > It's more than just that for me, I guess. Several libraries for geant have > > > this: > > > U _ZN5CLHEP7HepZHatE > > > > > > resulting in: > > > /usr/lib/geant4/libG4brep.so: undefined reference to `CLHEP::HepZHat' > > > > > > but nowhere in geant is defined any sort of symbol with 'Hat' in it. Although > > > lots of _ZN5CLHEP symbols are defined, these aren't. > > > > > > > My mistake. The're in libCLHEP, a separate package. > > The geant4 Makefiles assume these libraries from sci-physics/clhep are in > /usr/lib. I have no idea about sparc layout, but could it be that you CLHEP > libraries are somewhere else? > No, the problem was that I forgot about -lCLHEP. For me, the make files fail because they can't find the /usr/lib/geant4/liblist program nor the /usr/lib/geant4/libname.map file. Rather than chasing down which of many env variables would control this, I built a brute-force linker script and forgot about CLHEP. Once I noticed that, things started building at least. bicatali@gentoo.org 2008-08-22 15:58:50 0000 (In reply to comment #10) > about CLHEP. Once I noticed that, things started building at least. Are we done here? Thanks bicatali@gentoo.org 2008-09-23 11:40:08 0000 Need more tests. Re-open if it still fails. 159961 2008-07-09 17:27 0000 Fix global libs issues globalism.patch text/plain ZGlmZiAtLWdpdCBhL2dlYW50LTQuOS4xX3AwMi5lYnVpbGQgYi9nZWFudC00LjkuMV9wMDIuZWJ1 aWxkCmluZGV4IDU3NTRhYzAuLmZlOThjZDYgMTAwNjQ0Ci0tLSBhL2dlYW50LTQuOS4xX3AwMi5l YnVpbGQKKysrIGIvZ2VhbnQtNC45LjFfcDAyLmVidWlsZApAQCAtNzYsNiArNzYsOSBAQCBzcmNf dW5wYWNrKCkgewogCQktZSAnczokKEc0QklOKS8kKEc0U1lTVEVNKTokKEc0VE1QKTpnJyBcCiAJ CS1lICdzOiQoRzRUTVApLyQoRzRTWVNURU0pOiQoRzRUTVApOmcnIFwKIAkJc291cmNlL0dOVW1h a2VmaWxlIHx8IGRpZSAic2VkIEdOVW1ha2VmaWxlIGZhaWxlZCIKKwlzZWQgLWkgXAorCQktZSAn czokKEc0TElCKS8kKEc0U1lTVEVNKTokKEc0VE1QKTpnJyBcCisJCWNvbmZpZy9nbG9ibGliLmdt ayB8fCBkaWUgInNlZCBnbG9ibGliLmdtayBmYWlsZWQiCiB9CiAKIHNyY19jb21waWxlKCkgewpA QCAtMTI0LDE2ICsxMjcsMTYgQEAgc3JjX2NvbXBpbGUoKSB7CiAJZXhwb3J0IEc0TElCX0JVSUxE X1NIQVJFRD15CiAJZW1ha2UgfHwgZGllICJCdWlsZGluZyBzaGFyZWQgZ2VhbnQgZmFpbGVkIgog CisJaWYgdXNlIGdsb2JhbDsgdGhlbgorCQlleHBvcnQgRzRMSUJfVVNFX0dSQU5VTEFSPXkKKwkJ ZW1ha2UgZ2xvYmFsIHx8IGRpZSAiQnVpbGRpbmcgZ2xvYmFsIGxpYnJhcmllcyBmYWlsZWQiCisJ ZmkKKwogCWlmIHVzZSBzdGF0aWM7IHRoZW4KIAkJcm0gLXJmIHRtcAogCQlleHBvcnQgRzRMSUJf QlVJTERfU1RBVElDPXkgOyB1bnNldCBHNExJQl9CVUlMRF9TSEFSRUQKIAkJZW1ha2UgfHwgZGll ICJCdWlsZGluZyBzdGF0aWMgZ2VhbnQgZmFpbGVkIgogCWZpCi0KLQlpZiB1c2UgZ2xvYmFsOyB0 aGVuCi0JCWV4cG9ydCBHNExJQl9VU0VfR1JBTlVMQVI9eQotCQllbWFrZSBnbG9iYWwgfHwgZGll ICJCdWlsZGluZyBnbG9iYWwgbGlicmFyaWVzIGZhaWxlZCIKLQlmaQogfQogCiBnNF9jcmVhdGVf ZW52X3NjcmlwdCgpIHsK 160601 2008-07-16 20:11 0000 patch against version in portage v1.5 Rebuild-granular-libraries.patch text/plain RnJvbSAzYjFmN2FhMjUzMDQ0ZDU0MDE0NmI2OWRiY2U5NjZiZjEyNGNmZDg0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCZW5qYW1pbiBCYW5uaWVyIDxiZW5uaUBuZXRyb25hdXQuZGU+ CkRhdGU6IFdlZCwgMTYgSnVsIDIwMDggMTU6NDk6MTkgLTA0MDAKU3ViamVjdDogW1BBVENIXSBS ZWJ1aWxkIGdyYW51bGFyIGxpYnJhcmllcwoKIm1ha2UgZ2xvYmFsIiByZW1vdmVzIGFsbCB0aGUg Z3JhbnVsYXIgbGlicmFyaWVzIHdlIGJ1aWx0IGluIHRoZSBzdGVwCmJlZm9yZS4gIEkgaGFkIGEg bG9vayBhdCB0aGUgYnVpbGQgcHJvY2VzcyBpbiB0aGUgLi9Db25maWd1cmUgc2NyaXB0CihpbnN0 YWxsLnNoKTogdGhleSBidWlsZCBnbG9iYWwgZmlyc3QgYW5kIHRoZW4gdGhlIHJlc3QuIEhvd2V2 ZXIsCnRyeWluZyB0aGlzIG9yZGVyIGluIHRoZSBlYnVpbGQgZG9lcyBub3QgYnVpbGQgdGhlIGdy YW51bGFyIGxpYnJhcmllcwooIm5vIHJ1bGUgZm9yIG9iai5sYXN0IiBpbiAibWFrZSBnbG9iYWwi KS4KClRoaXMgcGF0Y2gganVzdCBtYWtlcyBzdXJlIHRoYXQgdGhlIGdyYW51bGFyIGxpYnJhcmll cyBhcmUgcmVidWlsZApmcm9tIHRoZSBvYmplY3QgZmlsZXMgdGhhdCBhcmUgc3RpbGwgYXJvdW5k IGluIGNhc2Ugd2UgYnVpbGQgZ2xvYmFsCmxpYnJhcmllcywgdG9vLgotLS0KIGdlYW50LTQuOS4x X3AwMi5lYnVpbGQgfCAgICAxICsKIDEgZmlsZXMgY2hhbmdlZCwgMSBpbnNlcnRpb25zKCspLCAw IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2dlYW50LTQuOS4xX3AwMi5lYnVpbGQgYi9nZWFu dC00LjkuMV9wMDIuZWJ1aWxkCmluZGV4IDE5ZGE2ZWEuLjBhMDE5YzUgMTAwNjQ0Ci0tLSBhL2dl YW50LTQuOS4xX3AwMi5lYnVpbGQKKysrIGIvZ2VhbnQtNC45LjFfcDAyLmVidWlsZApAQCAtMTMw LDYgKzEzMCw3IEBAIHNyY19jb21waWxlKCkgewogCWlmIHVzZSBnbG9iYWw7IHRoZW4KIAkJZXhw b3J0IEc0TElCX1VTRV9HUkFOVUxBUj15CiAJCWVtYWtlIGdsb2JhbCB8fCBkaWUgIkJ1aWxkaW5n IGdsb2JhbCBsaWJyYXJpZXMgZmFpbGVkIgorCQllbWFrZSB8fCBkaWUgIlJlYnVpbGRpbmcgc2hh cmVkIGdlYW50IGZhaWxlZCIKIAlmaQogCiAJaWYgdXNlIHN0YXRpYzsgdGhlbgotLSAKMS41LjYu MgoK