Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#36866 closed defect (fixed)

clhep @2.1.2.5 bypasses destroot when installing libCLHEP.dylib

Reported by: mojca (Mojca Miklavec) Owned by: cristiano.fontana@…
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: Cc: ryandesign (Ryan Carsten Schmidt)
Port: clhep

Description

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

Attachments (2)

clhep_add_dylib.diff (658 bytes) - added by mojca (Mojca Miklavec) 12 years ago.
Add a symlink to unversionsed libCLHEP.dylib(.a)
clhep_2.1.3.0.diff (771 bytes) - added by mojca (Mojca Miklavec) 12 years ago.
CLHEP 2.1.3.0 update including bugfix

Download all attachments as: .zip

Change History (17)

Changed 12 years ago by mojca (Mojca Miklavec)

Attachment: clhep_add_dylib.diff added

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

comment:1 Changed 12 years ago by jmroot (Joshua Root)

Cc: cristiano.fontana@… jmr@… removed
Owner: changed from macports-tickets@… to cristiano.fontana@…

comment:2 Changed 12 years ago by 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" )

comment:3 Changed 12 years ago by 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}

Changed 12 years ago by mojca (Mojca Miklavec)

Attachment: clhep_2.1.3.0.diff added

CLHEP 2.1.3.0 update including bugfix

comment:4 Changed 12 years ago by 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).

comment:5 Changed 12 years ago by 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
    }
}

comment:6 Changed 12 years ago by 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)

comment:7 Changed 12 years ago by jmroot (Joshua Root)

Summary: clhep: add symlink libCLHEP.dylib, else Geant4 cannot find itclhep @2.1.2.5 bypasses destroot when installing libCLHEP.dylib

comment:8 Changed 12 years ago by jmroot (Joshua Root)

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

comment:9 Changed 12 years ago by 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.

comment:10 Changed 12 years ago by 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?

Last edited 12 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:11 Changed 12 years ago by 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?

comment:12 Changed 12 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: newclosed

Fix to delete old library symlinks added in r99749.

comment:13 Changed 12 years ago by 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.

comment:14 Changed 12 years ago by 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.

comment:15 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

Cc Me!

Note: See TracTickets for help on using tickets.