Re: redefined data types in different packages - request for help
Hi Mojca,
since this beautiful example of Bad Code (TM) is inside (system) library
headers there's not much you can do without reporting upstream or resorting
to very rude measures like using your own patched tiff:
Without having a system here to test my suggestions, you might be able to
- configure tiff to not define this type name (or define it correctly in
the sense of portability and compatibility, at least).
- configure the software to try to avoid #including one or the other file
(WTH is cssmconfig.h, anyway?)
Regards
Titus
From: Mojca Miklavec mo...@macports.org
Sent: Samstag, 9. November 2013 15:15
To: MacPorts Development macports-dev@lists.macosforge.org
Subject: Re: redefined data types in different packages - request for help
On Sat, Nov 9, 2013 at 3:08 PM, Mojca Miklavec mo...@macports.org wrote:
Hi,
one of the problems I'm experiencing when compiling hugin-app is that
uint64 is defined both in Security.framework where it's
uint64-uint64_t as well as in tiff.h/tiffio.h where it gets defined
as unsigned long long.
How can one resolve such a conflict?
I'm sorry, I copied the wrong error. It should have been:
cd /path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project
/usr/bin/clang++ -DHUGIN_HSI -DWXUSINGDLL -D_FILE_OFFSET_BITS=64
-D__WXMAC__ -D__WXOSX_COCOA__ -D__WXOSX__ -pipe -Os
-D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0
-I/opt/local/include -arch x86_64
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/i
nclude/wx-3.0
-DNDEBUG -arch x86_64 -I/path/to/hugin-app/work/hugin-2013.0.0/src
-I/path/to/hugin-app/work/hugin-2013.0.0/src/hugin_base
-I/path/to/hugin-app/work/hugin-2013.0.0/src/foreign/vigra
-I/path/to/hugin-app/work/hugin-2013.0.0/src/celeste
-I/opt/local/include -I/opt/local/include/OpenEXR
-F//System/Library/Frameworks
-I/System/Library/Frameworks/GLUT.framework/Versions/A/Headers
-I/path/to/hugin-app/work/hugin-2013.0.0/src/foreign
-I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python
2.7
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/l
ib/wx/include/osx_cocoa-unicode-3.0
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/i
nclude/wx-3.0
-I/path/to/hugin-app/work/hugin-2013.0.0/src/hugin1-o
CMakeFiles/HuginStitchProject.dir/hugin_stitch_project.cpp.o -c
/path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project/hugin_stitc
h_project.cpp
In file included from
/path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project/hugin_stitc
h_project.cpp:46:
In file included from /opt/local/include/tiffio.h:33:
/opt/local/include/tiff.h:78:23: error: typedef redefinition with
different types ('unsigned long' vs 'uint64_t' (aka 'unsigned long
long'))
typedef TIFF_UINT64_T uint64;
^
//System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:53:18:
note: previous definition is here
typedef uint64_t uint64;
^
2 warnings and 1 error generated.
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Sun, Nov 10, 2013, at 12:47 AM, Joshua Root wrote: On 2013-11-10 05:35 , Craig Treleaven wrote: Perhaps just the documentation for depends_lib should be expanded to say that it indicates both compiled and interpreted linkages? It doesn't indicate anything about linkage, it indicates that the dependency is needed at both build time and run time. How does one indicate a runtime dependency that is checked for at configure time and not used for building or linking? I've been using depends_run, but I'm not sure that always works because of the configuration checking. Are these dependencies installed before configuration of the target port? Do we need to redefine (as per this thread) what the depends_* actually mean, to make checking for linkage versus usage, and when the usage is checked for and used (to my count: 3 different depends_*, I think as we have now)? - MLD ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Depends_build and depends_lib are installed prior to build phase, and depends_run prior to activate. Depends_extract for extract phase, etc. So a dependency marked as depends_run will not be installed prior to configuration. On Sun, 10 Nov 2013 07:23:47 -0500, Michael Dickens michae...@macports.org wrote: On Sun, Nov 10, 2013, at 12:47 AM, Joshua Root wrote: On 2013-11-10 05:35 , Craig Treleaven wrote: Perhaps just the documentation for depends_lib should be expanded to say that it indicates both compiled and interpreted linkages? It doesn't indicate anything about linkage, it indicates that the dependency is needed at both build time and run time. How does one indicate a runtime dependency that is checked for at configure time and not used for building or linking? I've been using depends_run, but I'm not sure that always works because of the configuration checking. Are these dependencies installed before configuration of the target port? Do we need to redefine (as per this thread) what the depends_* actually mean, to make checking for linkage versus usage, and when the usage is checked for and used (to my count: 3 different depends_*, I think as we have now)? - MLD ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 10, 2013, at 7:23 AM, Michael Dickens michae...@macports.org wrote: How does one indicate a runtime dependency that is checked for at configure time and not used for building or linking? As previously stated, one could use either depends_lib or depends_build + depends_run, because depends_lib does not currently mean anything other than required at both build time and run time. I've been using depends_run, but I'm not sure that always works because of the configuration checking. Are these dependencies installed before configuration of the target port? This is incorrect because there is no guarantee that the dependency will be present during the configure phase. Running port configure foo will not trigger installation of foo's runtime dependencies. It's easy to miss this if you always have the dependencies installed, or if you test with port install foo, which (I believe) installs all dependencies before starting on foo. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113152] trunk/dports
On Nov 10, 2013, at 8:04 PM, jerem...@macports.org wrote: Revision: 113152 https://trac.macports.org/changeset/113152 Author: jerem...@macports.org Date: 2013-11-10 17:04:28 -0800 (Sun, 10 Nov 2013) Log Message: --- multiple: Replace -fvi with -fi in autoreconf.args since base now includes --verbose Don't these all have to switch to autoreconf.args-append to avoid wiping out the default value? vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113152] trunk/dports
On Nov 10, 2013, at 17:18, Lawrence Velázquez lar...@macports.org wrote: On Nov 10, 2013, at 8:04 PM, jerem...@macports.org wrote: Revision: 113152 https://trac.macports.org/changeset/113152 Author: jerem...@macports.org Date: 2013-11-10 17:04:28 -0800 (Sun, 10 Nov 2013) Log Message: --- multiple: Replace -fvi with -fi in autoreconf.args since base now includes --verbose Don't these all have to switch to autoreconf.args-append to avoid wiping out the default value? The default value of autoreconf.args is empty, so it doesn't matter. smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113152] trunk/dports
On Nov 10, 2013, at 8:55 PM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: On Nov 10, 2013, at 17:18, Lawrence Velázquez lar...@macports.org wrote: Don't these all have to switch to autoreconf.args-append to avoid wiping out the default value? The default value of autoreconf.args is empty, so it doesn't matter. It's empty in release but not in trunk. http://trac.macports.org/changeset/113062 vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113155] trunk/dports/multimedia
On Nov 10, 2013, at 19:54, pixi...@macports.org wrote: Revision 113155 Author pixi...@macports.org Date 2013-11-10 17:54:29 -0800 (Sun, 10 Nov 2013) Log Message multimedia/mythweb.27: - New port for mythweb.27. Added Paths • trunk/dports/multimedia/mythweb.27/ • trunk/dports/multimedia/mythweb.27/Portfile • trunk/dports/multimedia/mythweb.27/files/ • trunk/dports/multimedia/mythweb.27/files/patch-mythweb.conf.diff Diff Added: trunk/dports/multimedia/mythweb.27/Portfile (0 = 113155) +depends_run port:php5-mysql php5- ports have been deprecated for a long time. Could you please use php53-mysql, php54-mysql or php55-mysql instead, or even offer php53, php54 and php55 variants to let the user choose? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113152] trunk/dports
On Nov 10, 2013, at 19:04, jerem...@macports.org wrote: Revision 113152 Author jerem...@macports.org Date 2013-11-10 17:04:28 -0800 (Sun, 10 Nov 2013) Log Message multiple: Replace -fvi with -fi in autoreconf.args since base now includes —verbose use_autoreconf yes -autoreconf.args -fvi +autoreconf.args -fi The default autoreconf.args in base in trunk are “--install --verbose”, equivalent to “-iv”. But if you’re going to overwrite autoreconf.args, as you do here, then any default value is irrelevant. If you want verbose, you need to specify verbose. Or, append to autoreconf.args instead of overwriting them: if you want to force, then you could: autoreconf.args-append --force ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113155] trunk/dports/multimedia
At 8:47 PM -0600 11/10/13, Ryan Schmidt wrote: On Nov 10, 2013, at 19:54, pixi...@macports.org wrote: Revision 113155 Author pixi...@macports.org Date 2013-11-10 17:54:29 -0800 (Sun, 10 Nov 2013) Log Message multimedia/mythweb.27: - New port for mythweb.27. Added Paths * trunk/dports/multimedia/mythweb.27/ * trunk/dports/multimedia/mythweb.27/Portfile * trunk/dports/multimedia/mythweb.27/files/ * trunk/dports/multimedia/mythweb.27/files/patch-mythweb.conf.diff Diff Added: trunk/dports/multimedia/mythweb.27/Portfile (0 = 113155) +depends_run port:php5-mysql php5- ports have been deprecated for a long time. Could you please use php53-mysql, php54-mysql or php55-mysql instead, or even offer php53, php54 and php55 variants to let the user choose? I'm the maintainer; pixilla pointed this out to me as well. The project plans to do away with MythWeb and replace it with a modern web frontend an internal http server, hopefully for the next release. I will look at updating php in the meantime. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113152] trunk/dports
On Nov 10, 2013, at 18:51, Ryan Schmidt ryandes...@macports.org wrote: On Nov 10, 2013, at 19:04, jerem...@macports.org wrote: Revision 113152 Author jerem...@macports.org Date 2013-11-10 17:04:28 -0800 (Sun, 10 Nov 2013) Log Message multiple: Replace -fvi with -fi in autoreconf.args since base now includes —verbose use_autoreconf yes -autoreconf.args -fvi +autoreconf.args -fi The default autoreconf.args in base in trunk are “--install --verbose”, equivalent to “-iv”. But if you’re going to overwrite autoreconf.args, as you do here, then any default value is irrelevant. If you want verbose, you need to specify verbose. Or, append to autoreconf.args instead of overwriting them: if you want to force, then you could: autoreconf.args-append --force The purpose of my doing this to all these ports (and ones that I did as I encountered them) was because '--verbose' was added to pre_args a couple months ago, and the --verbose flag increases verbosity the more it is used. Thus removing it from the port reduces the number of --verbose flags down to 1. I see that it was moved from pre_args into args in base a few days ago which completely defeats the purpose of this patch, so I need to not only revert this bug go back and revert all the places that I've changed it from -fvi to -fi over the past couple months... What was the reason for moving it from pre_args to args? I don't really see that in the commit message. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Passing '-arch pcc' to gfortran-mp-4.8: unrecognized command line option
On 2013-11-10 18:00 , Blair Zajac wrote: I was thinking that if gfortran doesn't accept -arch for any platform, then this looks like a ppc bug because nobody else has reported it for x86_64? Apparently recent FSF GCCs do have limited support for -arch. I think they only allow one arch to be specified, and I don't know if the support is limited to the C/C++ front end or particular archs. Here's part of the 'port -d -v install octave-devel' output: DEBUG: Environment: CPATH='/opt/local/include' CXXFLAGS='-pipe -Os -arch ppc' CFLAGS='-pipe -Os -arch ppc' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.5' PERL='/opt/local/bin/perl' CXX='/usr/bin/g++-4.2' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_octave-devel/octave-devel/work/.CC_PRINT_OPTIONS' F90FLAGS='-pipe -Os -m32' SED='/opt/local/bin/gsed' LDFLAGS='-arch ppc' FCFLAGS='-pipe -Os -m32' TEXI2PDF='/opt/local/bin/texi2pdf' OBJC='/usr/bin/gcc-4.2' OBJCXX='/usr/bin/g++-4.2' INSTALL='/usr/bin/install -c' F90='/opt/local/bin/gfortran-mp-4.8' FC='/opt/local/bin/gfortran-mp-4.8' PYTHON='' '' AWK='/opt/local/bin/gawk' FFLAGS='-pipe -Os -m32' OBJCXXFLAGS='-pipe -Os -arch ppc' OBJCFLAGS='-pipe -Os -arch ppc' F77='/opt/local/bin/gfortran-mp-4.8' CC_PRINT_OPTIONS='YES' GREP='/opt/local/bin/grep' CC='/usr/bin/gcc-4.2' TEXI2DVI='/opt/local/bin/texi2dvi' OK, so it's probably using the LDFLAGS. That's the trouble with using two different compilers, one of them supports this flag when linking and the other doesn't, and there's not really any way of letting configure know that. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On 2013-11-10 23:23 , Michael Dickens wrote: On Sun, Nov 10, 2013, at 12:47 AM, Joshua Root wrote: On 2013-11-10 05:35 , Craig Treleaven wrote: Perhaps just the documentation for depends_lib should be expanded to say that it indicates both compiled and interpreted linkages? It doesn't indicate anything about linkage, it indicates that the dependency is needed at both build time and run time. How does one indicate a runtime dependency that is checked for at configure time and not used for building or linking? I've been using depends_run, but I'm not sure that always works because of the configuration checking. Are these dependencies installed before configuration of the target port? Do we need to redefine (as per this thread) what the depends_* actually mean, to make checking for linkage versus usage, and when the usage is checked for and used (to my count: 3 different depends_*, I think as we have now)? - MLD If it needs to be there at configure time then it's depends_build or depends_lib. Since it's also needed at runtime, it's the latter. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
php5 (was: [113155] trunk/dports/multimedia)
On 2013-11-11 13:47 , Ryan Schmidt wrote: php5- ports have been deprecated for a long time. Could you please use php53-mysql, php54-mysql or php55-mysql instead, or even offer php53, php54 and php55 variants to let the user choose? If the php5-* stuff is deprecated, shouldn't the descriptions at least say so? In fact, shouldn't it all just be replaced_by php53-*? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: php5 (was: [113155] trunk/dports/multimedia)
On Nov 10, 2013, at 23:21, Joshua Root j...@macports.org wrote: On 2013-11-11 13:47 , Ryan Schmidt wrote: php5- ports have been deprecated for a long time. Could you please use php53-mysql, php54-mysql or php55-mysql instead, or even offer php53, php54 and php55 variants to let the user choose? If the php5-* stuff is deprecated, shouldn't the descriptions at least say so? In fact, shouldn't it all just be replaced_by php53-*? It should, but I had wanted all ports declaring dependencies on any php5- ports to provide php53/php54/php55 variants first. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
