Can't build GNU Octave because of missing/broken hdf5?
Hi all, I'm trying to build GNU Octave, but one of the pre-requisites hdf5 seems broken: ---> Fetching hdf5 ---> Attempting to fetch hdf5-1.6.5.tar.gz from ftp://ftp.hdfgroup.org/HDF5/current/src/ ---> Attempting to fetch hdf5-1.6.5.tar.gz from http://svn.macports.org/repository/macports/distfiles/hdf5 ---> Attempting to fetch hdf5-1.6.5.tar.gz from http://svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch hdf5-1.6.5.tar.gz from http://svn.macports.org/repository/macports/downloads/hdf5 Error: Target org.macports.fetch returned: fetch failed Error: The following dependencies failed to build: hdf5 Error: Status 1 encountered during processing. What should I do to fix it? Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- Beware the Lollipop of Mediocrity. Lick it once, and you suck forever.
On Sep 5, 2007, at 02:53, Erik de Castro Lopo wrote:
I'm trying to build GNU Octave, but one of the pre-requisites hdf5 seems broken:
---> Fetching hdf5 ---> Attempting to fetch hdf5-1.6.5.tar.gz from ftp:// ftp.hdfgroup.org/HDF5/current/src/ ---> Attempting to fetch hdf5-1.6.5.tar.gz from http:// svn.macports.org/repository/macports/distfiles/hdf5 ---> Attempting to fetch hdf5-1.6.5.tar.gz from http:// svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch hdf5-1.6.5.tar.gz from http:// svn.macports.org/repository/macports/downloads/hdf5 Error: Target org.macports.fetch returned: fetch failed Error: The following dependencies failed to build: hdf5 Error: Status 1 encountered during processing.
What should I do to fix it?
A bug about hdf5 has already been filed: http://trac.macosforge.org/projects/macports/ticket/12592 The maintainer has not yet responded.
I have built octave two days ago and have met this same problem. Here's the recipe. To work around it, edit the Portfile (/opt/local/var/macports/sources/rsync.macports.org/release/ports/science/hdf5/Portfile) and modify two things: * the version : replace 1.6.5 by 1.6.6 * the checksum: I did not keep a copy of the new checksum, but after you changed the version and tried again to "port install hdf5" there will be an error message in which the checksum is printed. So replace the current value by the expected one. No the build should go fine. When hdf5 has completed its build, execute sudo port install octave to finish the job. HTH Bernard Ryan Schmidt wrote:
On Sep 5, 2007, at 02:53, Erik de Castro Lopo wrote:
I'm trying to build GNU Octave, but one of the pre-requisites hdf5 seems broken:
---> Fetching hdf5 ---> Attempting to fetch hdf5-1.6.5.tar.gz from ftp:// ftp.hdfgroup.org/HDF5/current/src/ ---> Attempting to fetch hdf5-1.6.5.tar.gz from http:// svn.macports.org/repository/macports/distfiles/hdf5 ---> Attempting to fetch hdf5-1.6.5.tar.gz from http:// svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch hdf5-1.6.5.tar.gz from http:// svn.macports.org/repository/macports/downloads/hdf5 Error: Target org.macports.fetch returned: fetch failed Error: The following dependencies failed to build: hdf5 Error: Status 1 encountered during processing.
What should I do to fix it?
A bug about hdf5 has already been filed:
http://trac.macosforge.org/projects/macports/ticket/12592
The maintainer has not yet responded.
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Hi All, Finally got some free time to deal with the latest version of postgis again. It's building successfully within MP, but I'm still puzzled by the linking with the libiconv in /usr/lib/. I would like it to depend on the MP installed libiconv, to stay within MP's self-contained strategy. After installing, I checked it's dependencies with: apollo:~ jeff$ otool -L /opt/local/bin/pgsql2shp /opt/local/bin/pgsql2shp: /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /opt/local/lib/postgresql82/libpq.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) After uninstalling & cleaning, I modified the the PortFile to build without libiconv, resulting in: apollo:~ jeff$ otool -L /opt/local/bin/pgsql2shp /opt/local/bin/pgsql2shp: /opt/local/lib/postgresql82/libpq.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) Thinking I was doing something wrong, I backed out the 1.3.1 version and installed MP's included 1.2.1 version. otool reports the same findings. Read thru the nu MP guide, trying everything that looks like it would modify the configure & build environment. No luck. I did search the source folder with BBEdit looking for references to "iconv" and found about 149 of them, in configure, configure.in and makefile.config.in. Nothing stood out as direct reference to libiconv in /usr/lib. Before I attempt blindly modifying these files, has any experienced users/developers dealt with this type of problem before? Second, am I being too much of a purist, and should just accept the linking in /usr/lib? Thanks for your time, Jeff
On Sep 7, 2007, at 11:30 AM, Jeff Stubbs wrote:
After installing, I checked it's dependencies with:
apollo:~ jeff$ otool -L /opt/local/bin/pgsql2shp /opt/local/bin/pgsql2shp: /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /opt/local/lib/postgresql82/libpq.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10)
After uninstalling & cleaning, I modified the the PortFile to build without libiconv, resulting in:
apollo:~ jeff$ otool -L /opt/local/bin/pgsql2shp /opt/local/bin/pgsql2shp: /opt/local/lib/postgresql82/libpq.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10)
That looks like it worked (at least the way you describe it) ... it built without libiconv.
Thinking I was doing something wrong, I backed out the 1.3.1 version and installed MP's included 1.2.1 version. otool reports the same findings.
Read thru the nu MP guide, trying everything that looks like it would modify the configure & build environment. No luck.
Usually, it's just a matter of setting an argument that gets passed to configure (something like --with-iconv=${prefix}) if the project's configure script doesn't have an option like that, though, you have to do some more work to figure out how to coerce it's build system to do what you want.
I did search the source folder with BBEdit looking for references to "iconv" and found about 149 of them, in configure, configure.in and makefile.config.in. Nothing stood out as direct reference to libiconv in /usr/lib.
It's probably looking for iconv, and just searching /usr/lib before looking in ${prefix}/lib
Before I attempt blindly modifying these files, has any experienced users/developers dealt with this type of problem before?
Second, am I being too much of a purist, and should just accept the linking in /usr/lib?
Ideally, you should make it link against the macports version. If you can't figure out a way to make it work, it might be acceptable to have the version that doesn't link with iconv. You really don't want to have it linking against a non-macports iconv if at all possible. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
participants (5)
-
Bernard Desgraupes
-
Daniel J. Luke
-
Erik de Castro Lopo
-
Jeff Stubbs
-
Ryan Schmidt