Opened 9 years ago

Closed 9 years ago

#48991 closed update (fixed)

ldas-tools @2.4.2 Updated for latest release of software

Reported by: emaros Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch maintainer Cc: skymoo (Adam Mercer)
Port: ldas-tools

Description

This update is for ldas-tools 2.4.2 using the Xcode 7.0

Attachments (4)

patch-libraries-ldastoolsal-src-AtExit.cc.diff (575 bytes) - added by emaros 9 years ago.
Patch file for AtExit.cc needed for Xcode 7.0
patch-libraries-ldastoolsal-src-TaskThread.cc.diff (375 bytes) - added by emaros 9 years ago.
Patch file for TaskThread.cc needed for Xcode 7.0
main.log (538.5 KB) - added by skymoo (Adam Mercer) 9 years ago.
Portfile-ldas-tools.diff (2.0 KB) - added by emaros 9 years ago.
Modifications to the Portfile

Download all attachments as: .zip

Change History (23)

Changed 9 years ago by emaros

Patch file for AtExit.cc needed for Xcode 7.0

Changed 9 years ago by emaros

Patch file for TaskThread.cc needed for Xcode 7.0

comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned

Thanks.

comment:2 Changed 9 years ago by skymoo (Adam Mercer)

If the patchfiles are going to be committed to SVN you don't need to include the checksums in the Portfile, these are only needed if they are downloaded.

However, if I remove the checksums for the patchfiles then this still fails for me, on El Capitan, with the following:

:info:build     /usr/bin/python ./framecpp_sample.py
:info:build Traceback (most recent call last):
:info:build   File "./framecpp_sample.py", line 6, in <module>
:info:build     import frameCPP
:info:build   File "/opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/frameCPP.py", line 33, in <module>
:info:build     _frameCPP = swig_import_helper()
:info:build   File "/opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/frameCPP.py", line 25, in swig_import_helper
:info:build     import _frameCPP
:info:build ImportError: dlopen(/opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/.libs/_frameCPP.so, 2): Library not loaded: /opt/local/lib/libframecpp.6.dylib
:info:build   Referenced from: /opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/.libs/_frameCPP.so
:info:build   Reason: image not found

I'll attach the full build log. I think the problem here is that the system python is being used, so the appropriate libraries can't be found. I think you need to specify that the MacPorts python should be used (using configure.python), otherwise it's just going to use whatever python is in the environment.

Changed 9 years ago by skymoo (Adam Mercer)

Attachment: main.log added

comment:3 Changed 9 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:4 Changed 9 years ago by emaros

Looking into the issue, I have discovered that what I need is to specify the line

configure.python "python${v}"

What would be most ideal is if I could fully qualify the path to the version specific python executable. Ideas on how to do this? Also, when I submit the patch, should it replace the current Portfile patch or be relative to the existing patch.

Version 0, edited 9 years ago by emaros (next)

comment:5 in reply to:  4 ; Changed 9 years ago by skymoo (Adam Mercer)

Replying to ed.maros@…:

What would be most ideal is if I could fully qualify the path to the version specific python executable. Ideas on how to do this?

Would the following work?

configure.python ${prefix}/bin/python${v}

Also, when I submit the patch, should it replace the current Portfile patch or be relative to the existing patch.

Relative to what's in SVN would probably make more sense.

comment:6 in reply to:  5 Changed 9 years ago by emaros

Replying to ram@…:

Replying to ed.maros@…:

What would be most ideal is if I could fully qualify the path to the version specific python executable. Ideas on how to do this?

Would the following work?

configure.python ${prefix}/bin/python${v}

Trying this now. I was just concerned that it wouldn't since I need the value at configure time.

Also, when I submit the patch, should it replace the current Portfile patch or be relative to the existing patch.

Relative to what's in SVN would probably make more sense.

comment:7 Changed 9 years ago by emaros

I have uploaded a new patch for the Portfile to address the ElCapitan issue. I have added a single line which directs the build to use the MacPorts version specific Python interpreter as directed by the variant option.

comment:8 in reply to:  7 ; Changed 9 years ago by skymoo (Adam Mercer)

Replying to ed.maros@…:

I have uploaded a new patch for the Portfile to address the ElCapitan issue. I have added a single line which directs the build to use the MacPorts version specific Python interpreter as directed by the variant option.

The checksums for the patches are still present and there is no python interpreter specified, are you sure this is the new patch?

comment:9 in reply to:  8 Changed 9 years ago by emaros

Replying to ram@…:

Replying to ed.maros@…:

I have uploaded a new patch for the Portfile to address the ElCapitan issue. I have added a single line which directs the build to use the MacPorts version specific Python interpreter as directed by the variant option.

The checksums for the patches are still present and there is no python interpreter specified, are you sure this is the new patch?

Sorry. I was working on too many systems. I have uploaded the modified patch. It still has the checksums of the patches because I was unable to do a port install without them. Perhaps I do not have my system configured properly for testing purposes. My model for testing is that I have the files in a local directory and do 'sudo port install'. Is this 'forcing' me into having to 'download' the patches (which I accomplish by copying them to the appropriate distfiles location)?

comment:10 Changed 9 years ago by skymoo (Adam Mercer)

If you put the patchfiles into a sub-directory called files at the same level as the Portfile then they should be found and you won't need the checksums.

I do have a question about the following hunk in the patch:

@@ -30,7 +40,7 @@
     configure.args-append --disable-cxx11
 }
 
-depends_lib    path:lib/libssl.dylib:openssl \
+depends_lib    port:openssl \
                port:zlib \
                port:bzip2 \
                port:flex
@@ -47,17 +57,19 @@

The path dependency for libssl.dylib was added so that libressl could be used instead of openssl, as you've changed this back is there some reason that libressl can't be used to satisfy the libssl dependency?

Also there is inconsistent whitespace usage, for example mixed tab and space usage. Can you use one or the other?

I have a test build going now and I'll report back on whether that builds or not once the test has completed.

comment:11 in reply to:  10 ; Changed 9 years ago by skymoo (Adam Mercer)

Replying to ram@…:

I have a test build going now and I'll report back on whether that builds or not once the test has completed.

The build completed successfully.

comment:12 in reply to:  11 Changed 9 years ago by emaros

Replying to ram@…:

Replying to ram@…:

I have a test build going now and I'll report back on whether that builds or not once the test has completed.

The build completed successfully.

Based on your suggestions, I am making some corrections that I will upload after verification.

comment:13 Changed 9 years ago by emaros

New version has been uploaded with consistent white spaces, no checksums for patches and removal of unneeded openssl library dependency.

comment:14 Changed 9 years ago by skymoo (Adam Mercer)

Are you sure that ssl is unneeded as libframecpp8.dylib, for example, is linked against libcrypto from openssl:

$ otool -L libframecpp8.dylib
libframecpp8.dylib:
	/opt/local/lib/libframecpp8.4.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecpp7.2.dylib (compatibility version 3.0.0, current version 3.1.0)
	/opt/local/lib/libframecpp6.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp4.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp3.3.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecppcmn.4.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
$ port provides /opt/local/lib/libcrypto.1.0.0.dylib
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
$

comment:15 in reply to:  14 Changed 9 years ago by emaros

Replying to ram@…:

Are you sure that ssl is unneeded as libframecpp8.dylib, for example, is linked against libcrypto from openssl:

$ otool -L libframecpp8.dylib
libframecpp8.dylib:
	/opt/local/lib/libframecpp8.4.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecpp7.2.dylib (compatibility version 3.0.0, current version 3.1.0)
	/opt/local/lib/libframecpp6.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp4.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp3.3.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecppcmn.4.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
$ port provides /opt/local/lib/libcrypto.1.0.0.dylib
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
$

Good catch. I will put it back. Question is system version vs MacPorts version.

comment:16 Changed 9 years ago by skymoo (Adam Mercer)

The MacPorts version should be used but use the path:lib/libssl.dylib:openssl style dependency so that either libressl or openssl can provide dependency, unless libressl can't be used for some reason.

Changed 9 years ago by emaros

Attachment: Portfile-ldas-tools.diff added

Modifications to the Portfile

comment:17 Changed 9 years ago by emaros

New version with the proper ssl library reference

comment:18 Changed 9 years ago by skymoo (Adam Mercer)

Looks good to me.

Ryan: As this is assigned to you do you have any comments or concerns?

comment:19 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

Committed in r141069.

I removed the quotes around ${prefix}/bin/python${v} because they are not needed.

I made the python27 variant the default only if the other python variant was not already selected. See PortfileRecipes#default_variants.

I changed "configure.args-strsed s/--disable-python/--enable-python/" which had already been in the portfile to "configure.args-replace --disable-python --enable-python"

Note: See TracTickets for help on using tickets.