Add port for h3dutil

[daniel.evestedt@…]

Adding Portfile for h3dutil, part of the H3D framwork (www.h3dapi.org)

[ryandesign (Ryan Carsten Schmidt)]

"support" is not a valid maintainer name.

Do we know what version(s) of the GPL this is under?

[daniel.evestedt@…]

Replying to ryandesign@…:

"support" is not a valid maintainer name.

Do we know what version(s) of the GPL this is under?

It is GPLv2.

Why is support not a valid name? The reason for using it is that it is a company that maintains the port and that address will go to several developers at the company.

[ryandesign (Ryan Carsten Schmidt)]

Replying to daniel.evestedt@…:

It is GPLv2.

Ok, then we should set the license field to "GPL-2". Unless the license is GPLv2 or later, in which case it should be "GPL-2+". And that does appear to be the case, based on what I see in src/H3DUtil.cpp:

//    H3DUtil is free software; you can redistribute it and/or modify
//    it under the terms of the GNU General Public License as published by
//    the Free Software Foundation; either version 2 of the License, or
//    (at your option) any later version.

Why is support not a valid name? The reason for using it is that it is a company that maintains the port and that address will go to several developers at the company.

You've listed two maintainers, "support" and "sensegraphics.com:support". Without a domain, just listing "support" means "support at macports dot org" which isn't a valid email address. :) The other one, which expands to "support at sensegraphics dot com", is fine, assuming that's a valid email address. Note that when bug reports are submitted for this port, someone will assign the ticket to "support at sensegraphics dot com", which will cause emails to be sent to that address by our issue tracker.

Is there a way the livecheck could be fixed? It currently fails:

$ port livecheck
Error: cannot check if h3dutil was updated (The requested URL returned error: 406)

[daniel.evestedt@…]

Fix to work with livecheck and correct license and maintainer address.

[daniel.evestedt@…]

Replying to ryandesign@…:

Replying to daniel.evestedt@…:

It is GPLv2.

Ok, then we should set the license field to "GPL-2". Unless the license is GPLv2 or later, in which case it should be "GPL-2+". And that does appear to be the case, based on what I see in src/H3DUtil.cpp:

//    H3DUtil is free software; you can redistribute it and/or modify
//    it under the terms of the GNU General Public License as published by
//    the Free Software Foundation; either version 2 of the License, or
//    (at your option) any later version.

Ok, fixed.

Why is support not a valid name? The reason for using it is that it is a company that maintains the port and that address will go to several developers at the company.

You've listed two maintainers, "support" and "sensegraphics.com:support". Without a domain, just listing "support" means "support at macports dot org" which isn't a valid email address. :) The other one, which expands to "support at sensegraphics dot com", is fine, assuming that's a valid email address. Note that when bug reports are submitted for this port, someone will assign the ticket to "support at sensegraphics dot com", which will cause emails to be sent to that address by our issue tracker.

Ok, sorry, did not realize that. Fixed.

Is there a way the livecheck could be fixed? It currently fails:

$ port livecheck
Error: cannot check if h3dutil was updated (The requested URL returned error: 406)
}}

Updated to work with livecheck. Please let me know if there is anything else that needs fixing. When this one is approved I will go on and update the other submissions that I did which have the same issues.

[kurthindenburg (Kurt Hindenburg)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

I can't get 1.2.0 or 1.3.0 to build - does it work for you on Mavericks?

:info:build Undefined symbols for architecture x86_64:
:info:build   "__libiconv_version", referenced from:
:info:build       OFCharacterEncoding::getLibraryVersionString() in libofstd.a(ofchrenc.o)
:info:build   "_libiconv", referenced from:
:info:build       OFCharacterEncoding::convertString(void*, char const*, unsigned long, OFString&, bool) in libofstd.a(ofchrenc.o)
:info:build   "_libiconv_close", referenced from:
:info:build       OFCharacterEncoding::closeDescriptor(void*&) in libofstd.a(ofchrenc.o)
:info:build   "_libiconv_open", referenced from:
:info:build       OFCharacterEncoding::openDescriptor(void*&, OFString const&, OFString const&) in libofstd.a(ofchrenc.o)
:info:build   "_libiconvctl", referenced from:
:info:build       OFCharacterEncoding::convertString(void*, char const*, unsigned long, OFString&, bool) in libofstd.a(ofchrenc.o)
:info:build   "_locale_charset", referenced from:
:info:build       OFCharacterEncoding::updateLocaleEncoding() in libofstd.a(ofchrenc.o)
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)}+

[ryandesign (Ryan Carsten Schmidt)]

I get the same error. libofstd.a is part of dcmtk, and it seems to use libiconv functions, but h3dutil's build process has not requested to link with libiconv, hence the symbols are missing. dcmtk doesn't seem to provide a pkg-config file or -config script, so I'm not sure how h3dutil decides what libraries to link with.

[daniel.evestedt@…]

Replying to ryandesign@…:

I get the same error. libofstd.a is part of dcmtk, and it seems to use libiconv functions, but h3dutil's build process has not requested to link with libiconv, hence the symbols are missing. dcmtk doesn't seem to provide a pkg-config file or -config script, so I'm not sure how h3dutil decides what libraries to link with.

I am running Mountain Lion on the system here and cannot seem to be able to reproduce this problem. Is this for Mavericks only? I seem to recall I had a similar issue a few years back with Snow Leopard that I could solve by installing dcmtk from source instead of the pre-compiled binary. Could you please try this and see if it makes a difference for you?

[ryandesign (Ryan Carsten Schmidt)]

I am on Yosemite beta, and I am building from source. I can try on earlier OS versions later. dcmtk takes some time to build.

[daniel.evestedt@…]

Replying to ryandesign@…:

I am on Yosemite beta, and I am building from source. I can try on earlier OS versions later. dcmtk takes some time to build.

I can try on a Mavericks system during the weekend and see if I get the same problem.

[ryandesign (Ryan Carsten Schmidt)]

Confirmed issue also exists on Mavericks, and issue does not exist on Mountain Lion.

However, on Mountain Lion, I saw a different error: The following file was recorded as part of the port's contents:

  /Volumes/Data/macports/mountainlion/var/macports/build/_Volumes_Data_macports_dports_graphics_h3dutil/h3dutil/work/h3dutil-1.3.0/include/H3DUtil/H3DUtil.h

(where /Volumes/Data/macports/mountainlion is my MacPorts prefix and /Volumes/Data/macports/dports is my ports tree).

It's the same file that also got installed to the proper location:

  /Volumes/Data/macports/mountainlion/include/H3DUtil/H3DUtil.h

I'm not sure how this problem occurred or how best to correct it. Unfortunately this project uses cmake, which is very difficult for me to understand.

[daniel.evestedt@…]

Replying to ryandesign@…:

Confirmed issue also exists on Mavericks, and issue does not exist on Mountain Lion.

However, on Mountain Lion, I saw a different error: The following file was recorded as part of the port's contents:

  /Volumes/Data/macports/mountainlion/var/macports/build/_Volumes_Data_macports_dports_graphics_h3dutil/h3dutil/work/h3dutil-1.3.0/include/H3DUtil/H3DUtil.h

(where /Volumes/Data/macports/mountainlion is my MacPorts prefix and /Volumes/Data/macports/dports is my ports tree).

It's the same file that also got installed to the proper location:

  /Volumes/Data/macports/mountainlion/include/H3DUtil/H3DUtil.h

I'm not sure how this problem occurred or how best to correct it. Unfortunately this project uses cmake, which is very difficult for me to understand.

H3DUtil.h is automatically generated by CMake when H3DUtil is built. I think the location was changed between 1.2.0 and 1.3.0 and it is then put into place on install. How are you using 1.3.0 though? 1.2.0 seems to be the one in the current MacPorts version for me at least.

[daniel.evestedt@…]

Replying to daniel.evestedt@…:

Replying to ryandesign@…:

Confirmed issue also exists on Mavericks, and issue does not exist on Mountain Lion.

However, on Mountain Lion, I saw a different error: The following file was recorded as part of the port's contents:

  /Volumes/Data/macports/mountainlion/var/macports/build/_Volumes_Data_macports_dports_graphics_h3dutil/h3dutil/work/h3dutil-1.3.0/include/H3DUtil/H3DUtil.h

(where /Volumes/Data/macports/mountainlion is my MacPorts prefix and /Volumes/Data/macports/dports is my ports tree).

It's the same file that also got installed to the proper location:

  /Volumes/Data/macports/mountainlion/include/H3DUtil/H3DUtil.h

I'm not sure how this problem occurred or how best to correct it. Unfortunately this project uses cmake, which is very difficult for me to understand.

H3DUtil.h is automatically generated by CMake when H3DUtil is built. I think the location was changed between 1.2.0 and 1.3.0 and it is then put into place on install. How are you using 1.3.0 though? 1.2.0 seems to be the one in the current MacPorts version for me at least.

I tried in Mavericks and get the same issue. I tried to track it down and found out a few things. The dcmtk that is used for Mavericks is a snapshot version of the dcmtk code and not an official release. It seems to not be in a fully stable state yet. There are two ways to build dcmtk, CMake or configure. If using CMake dcmtk build will fail with the same errors as H3DUtil when linking applications or shared libraries. configure seems to work though.

I would recommend to have the default build of dcmtk to be without libiconv and add support for it as a variant. Otherwise all libraries that previously used MacPorts dcmtk will fail on Mavericks. The best solution would be to provide shared libraries as well which would avoid this linking problem. However since the CMake build for shared libraries fails and configure does not seem to have this option there is no simple way to do that.

[ryandesign (Ryan Carsten Schmidt)]

Replying to daniel.evestedt@…:

How are you using 1.3.0 though? 1.2.0 seems to be the one in the current MacPorts version for me at least.

There is no MacPorts version of h3dutil yet; this ticket is as yet unresolved. When the ticket was filed, 1.2.0 was presumably the current version, and I experienced the described problem with it. I then saw that in the mean time 1.3.0 had been released, and I updated my local portfile to that version, but the problem remained.

I have identified the portion of h3dutil's CMakeLists.txt responsible for this and have added a patch to correct it.

Replying to daniel.evestedt@…:

The dcmtk that is used for Mavericks is a snapshot version of the dcmtk code and not an official release. It seems to not be in a fully stable state yet. There are two ways to build dcmtk, CMake or configure. If using CMake dcmtk build will fail with the same errors as H3DUtil when linking applications or shared libraries. configure seems to work though.

dcmtk was changed to use a snapshot for all OS X versions, and to build using cmake, in r128998, so its behavior is now consistent across OS X versions.

I would recommend to have the default build of dcmtk to be without libiconv and add support for it as a variant. Otherwise all libraries that previously used MacPorts dcmtk will fail on Mavericks.

This is not a good idea. This would result in the following problem: users who installed dcmtk with this hypothetical libiconv variant would then find that ports that depend on dcmtk would fail to build.

The best solution would be to provide shared libraries as well which would avoid this linking problem. However since the CMake build for shared libraries fails and configure does not seem to have this option there is no simple way to do that.

dcmtk also installs dynamic libraries as of r128998.

It seems the undefined symbol errors we were experiencing with h3dutil on Mavericks and later due to the snapshot are no longer occurring, so there's no longer a reason not to commit this port. Committed it in r133713.

Not previously discussed: I added a zlib dependency because it does link with it.