Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#38919 closed submission (fixed)

Add port for h3dutil

Reported by: daniel.evestedt@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: ryandesign (Ryan Schmidt), kurthindenburg (Kurt Hindenburg)
Port: h3dutil

Description

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

Attachments (2)

Portfile (1.0 KB) - added by daniel.evestedt@… 7 years ago.
h3dutil.diff (898 bytes) - added by daniel.evestedt@… 7 years ago.
Fix to work with livecheck and correct license and maintainer address.

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by daniel.evestedt@…

Attachment: Portfile added

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

Cc: ryandesign@… added
Port: h3dutil added

"support" is not a valid maintainer name.

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

comment:2 in reply to:  1 ; Changed 7 years ago by 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.

comment:3 in reply to:  2 ; Changed 7 years ago by ryandesign (Ryan 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)

Changed 7 years ago by daniel.evestedt@…

Attachment: h3dutil.diff added

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

comment:4 in reply to:  3 Changed 7 years ago by 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.

comment:5 Changed 6 years ago by kurthindenburg (Kurt Hindenburg)

Cc: khindenburg@… added

Cc Me!

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

comment:7 Changed 6 years ago by ryandesign (Ryan 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.

comment:8 in reply to:  7 Changed 6 years ago by 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?

comment:9 Changed 6 years ago by ryandesign (Ryan 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.

comment:10 in reply to:  9 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by ryandesign (Ryan 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.

comment:12 in reply to:  11 ; Changed 6 years ago by 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.

comment:13 in reply to:  12 ; Changed 6 years ago by 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.

comment:14 in reply to:  13 Changed 6 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: newclosed

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.

Last edited 6 years ago by ryandesign (Ryan Schmidt) (previous) (diff)
Note: See TracTickets for help on using tickets.