clhep @2.1.2.5 bypasses destroot when installing libCLHEP.dylib

[mojca (Mojca Miklavec)]

I'm not sure if this is a bug in Geant4 or CLHEP, but without /opt/local/lib/libCLHEP.dylib and /opt/local/lib/libCLHEP.a compiling Geant4 9.5 and Gate doesn't work. I'm attaching a patch, but I hope that the need for this patch will go away in future.

(If anyone knows of a better way to fix CLHEP's CMake files, feel free to suggest a different patch for source files.)

[mojca (Mojca Miklavec)]

Add a symlink to unversionsed libCLHEP.dylib(.a)

[mojca (Mojca Miklavec)]

I was wrong about the fact that clhep doesn't install libCLHEP.dylib(.a). It does install the two files, but they are created in /opt/local/lib instead of being put to DESTDIR first. From that point of view the above mentioned patch is not entirely correct. I'll try to get it fixed upstream and come back to this.

The problem presumably lies in cmake/Modules/ClhepBuildLibrary.cmake and two files which call

execute_process(COMMAND "/opt/local/bin/cmake" -E create_symlink libCLHEP-2.1.2.5.dylib libCLHEP.dylib WORKING_DIRECTORY "/opt/local/lib" )

execute_process(COMMAND "/opt/local/bin/cmake" -E create_symlink libCLHEP-2.1.2.5.a libCLHEP.a WORKING_DIRECTORY "/opt/local/lib" )

[mojca (Mojca Miklavec)]

This is the temporary (ugly) patch that I came up with, but it makes sense to wait for the next release of CLHEP before applying it:

--- Portfile
+++ Portfile
@@ -6,6 +6,7 @@
 
 name                clhep
 version             2.1.2.5
+revision            1
 categories          science
 maintainers         pd.infn.it:cristiano.fontana
 license             LGPL-3
@@ -27,6 +28,8 @@
 
 post-extract {
     file mkdir ${configure.dir}
+    # this is just a dirty hack that installs symlinks to proper location; it should be fixed upstream
+    reinplace "s|\$ENV\{DESTDIR\}|${destroot}|" ${worksrcpath}/cmake/Modules/ClhepBuildLibrary.cmake
 }
 
 configure.post_args ${worksrcpath}

[mojca (Mojca Miklavec)]

CLHEP 2.1.3.0 update including bugfix

[mojca (Mojca Miklavec)]

Can someone please update CLHEP to 2.1.3.0? That version includes a fix for the above mentioned problem (it has just been fixed upstream). I'm also willing to take over maintenance (the author doesn't seem to respond to any ticket).

[mojca (Mojca Miklavec)]

Optionally one might also consider deleting /opt/local/lib/libCLHEP.dylib and /opt/local/lib/libCLHEP.a in case they were installed by previous version of CLHEP without belonging to CLHEP (and keep that patch in the port for a while). So something like:

# remove in November 2013
pre-activate {
    if [file exists ${prefix}/lib/libCLHEP.dylib] {
        delete ${prefix}/lib/libCLHEP.dylib
    }
    if [file exists ${prefix}/lib/libCLHEP.a] {
        delete ${prefix}/lib/libCLHEP.a
    }
}

[mf2k (Frank Schima)]

I just installed version 2.1.3.0 with your patch and it does install /opt/local/lib/libCLHEP.dylib.

Here is the output:

$ otool -L /opt/local/lib/libCLHEP.dylib
/opt/local/lib/libCLHEP.dylib:
	/opt/local/lib/libCLHEP-2.1.3.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

[jmroot (Joshua Root)]

You should check that the files are unregistered before you delete them. See gdbm for example.

[mf2k (Frank Schima)]

Maintainer timeout. Updated to 2.1.3.0 in r99711. I did not add the optional code from comment:5 based on email with Mojca.

[mojca (Mojca Miklavec)]

According to jmr (looking at gdbm):

--- Portfile
+++ Portfile
@@ -39,5 +39,14 @@ post-build {
     }
 }
 
+# clean the files bypassing destroot (a bug in 2.1.2.5)
+# may be removed in November 2013
+pre-activate {
+    foreach file {${prefix}/lib/libCLHEP.a ${prefix}/lib/libCLHEP.dylib} {
+    if {[file exists ${file}] && [registry_file_registered ${file}] == "0"} {
+        delete ${file}
+    }
+}
+
 livecheck.type      regex
 livecheck.regex     {<b>([0-9.]+)</b>}

But I don't really understand why [registry_file_registered ${file}] == "0" is needed. I would only do

pre-activate {
    foreach file {${prefix}/lib/libCLHEP.a ${prefix}/lib/libCLHEP.dylib} {
    if [file exists ${file}] {
        delete ${file}
    }
}

In case that the two files actually belong to a previous version of the port: aren't they already removed by the time pre-activate takes place?

[mf2k (Frank Schima)]

@mojca: Your code does not work for me. I am not able to get this to work. Here is my latest attempt:

pre-activate {
    foreach file {lib/libCLHEP.a lib/libCLHEP.dylib} {
        set filepath ${prefix}/${file}
        puts ${filepath}
        if {[file exists ${filepath}]} {
            puts "file exists!"
            if {[registry_file_registered ${filepath}] == "0"} {
                puts "file is in registry"
                if {[catch {delete ${filepath}}]} {
                    ui_warn "Cannot delete ${filepath}; please remove it manually"
                }
            } else {
                puts "file is NOT in registry!"
            }
        } else {
            puts "file does NOT exist!!!"
        }
    }
}

What happens is that the correct filename appears for each file, but the file exists condition does not pass even though the file definitely does exist on my computer and is not registered. Ideas anyone?

[mf2k (Frank Schima)]

Fix to delete old library symlinks added in r99749.

[mojca (Mojca Miklavec)]

I admit that I cloned the code from other ports without testing since I was trying to catch a deadline. However - if "file exists" doesn't work, there is a problem in other ports.

[ryandesign (Ryan Carsten Schmidt)]

"file exists" works, but in the case of symlinks (which libCLHEP.a and libCLHEP.dylib are), it answers about the file the symlink points to, not about the symlink itself. We need a new procedure in MacPorts base that will answer about the symlink itself—like the procedure I just committed to the muniversal portgroup in r99808 to solve #35226.

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!