Re: redefined data types in different packages - request for help
Hoping this gets fixed sometime soon, because for some reason it's been screwing with my `camlimages` build... On Tue, Nov 12, 2013 at 7:20 AM, Titus von Boxberg ti...@v9g.de wrote: Am 11.11.2013 20:08, schrieb Mojca Miklavec: On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote: 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). I cannot configure it to not define the type name uint64. This type name is used all over the place. The solution might be to define it to uint64_t instead of unsigned long. Yes, that seems reasonable as long as uint64_t is guaranteed to be defined before the typedef of uint64 happens. Maybe you could patch tiffconfig.h.in or something else in tiff's configuration phase. Regards Titus ___ 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: redefined data types in different packages - request for help
Am 11.11.2013 20:08, schrieb Mojca Miklavec: On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote: 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). I cannot configure it to not define the type name uint64. This type name is used all over the place. The solution might be to define it to uint64_t instead of unsigned long. Yes, that seems reasonable as long as uint64_t is guaranteed to be defined before the typedef of uint64 happens. Maybe you could patch tiffconfig.h.in or something else in tiff's configuration phase. Regards Titus ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: redefined data types in different packages - request for help
On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote: 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 http://bugzilla.maptools.org/show_bug.cgi?id=2464 or resorting to very rude measures like using your own patched tiff: MacPorts sometimes fixes upstream bugs in order to make the ports compile. This would probably be another such case. The problem is that I'm not sure how to properly fix this in 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). I cannot configure it to not define the type name uint64. This type name is used all over the place. The solution might be to define it to uint64_t instead of unsigned long. - configure the software to try to avoid #including one or the other file (WTH is cssmconfig.h, anyway?) The file cssmconfig.h is part of Security.framework. What it is used for - no idea at all. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
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
redefined data types in different packages - request for help
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?
cd /path/to/hugin-app/work/hugin-2013.0.0/src/foreign/vigra/vigra_impex
/usr/bin/clang++ -DHUGIN_HSI -Dhuginvigraimpex_EXPORTS -pipe -Os
-D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0
-I/opt/local/include -arch x86_64 -DNDEBUG -arch x86_64 -fPIC
-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/python2.7
-o CMakeFiles/huginvigraimpex.dir/tiff.cxx.o -c
/path/to/hugin-app/work/hugin-2013.0.0/src/foreign/vigra/vigra_impex/tiff.cxx
In file included from
/path/to/hugin-app/work/hugin-2013.0.0/src/foreign/vigra/vigra_impex/tiff.cxx:76:
/opt/local/include/tiff.h:79:18: error: typedef redefinition with
different types ('uint64_t' (aka 'unsigned long long') vs 'unsigned
long')
typedef uint64_t uint64;
^
/opt/local/include/tiff.h:78:23: note: previous definition is here
typedef TIFF_UINT64_T uint64;
^
1 error generated.
Thank you,
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
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/include/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/python2.7
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/include/osx_cocoa-unicode-3.0
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/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_stitch_project.cpp
In file included from
/path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project/hugin_stitch_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
Re: redefined data types in different packages - request for help
Looks like this is C++. There might be something you can do with namespaces.
David
On Sat, Nov 9, 2013 at 9:15 AM, Mojca Miklavec mo...@macports.org wrote:
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/include/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/python2.7
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/include/osx_cocoa-unicode-3.0
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/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_stitch_project.cpp
In file included from
/path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project/hugin_stitch_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: redefined data types in different packages - request for help
Hi Mojca - Since the CMake PortGroup was recently modified to include
CPPFLAGS=-I${prefix}/include, I've been having to remove that setting
from my ports which use this group because it grabs already-installed
headers instead of those local to the port (CPPFLAGS gets propagated to
CFLAGS and CXXFLAGS). Ditto for LDFLAGS and -L${prefix}/lib. Maybe
this change will help? I note from the included compile command that
-I/opt/local/include is the first include directive, so that directory
should be searched before the others listed. - MLD
On Sat, Nov 9, 2013, at 09:15 AM, Mojca Miklavec wrote:
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/include/wx-3.0
[snip]
In file included from
/path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project/hugin_stitch_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;
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: redefined data types in different packages - request for help
On Nov 9, 2013, at 14:00, Michael Dickens wrote:
Hi Mojca - Since the CMake PortGroup was recently modified to include
CPPFLAGS=-I${prefix}/include, I've been having to remove that setting
from my ports which use this group because it grabs already-installed
headers instead of those local to the port (CPPFLAGS gets propagated to
CFLAGS and CXXFLAGS).
https://trac.macports.org/ticket/40656 should fix this.
Ditto for LDFLAGS and -L${prefix}/lib.
But not this. I'm not aware of a similar directive we could use to fix this for
libraries. ___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: redefined data types in different packages - request for help
Using -isystem ${prefix}/include seems like a great solution to using
CPATH; it seems to work all the way back to clang 2.9 and gcc 4.2,
maybe further, while CPATH started with (I think) clang 2.9 -- I'll
have to investigate using it for qt4-mac.
I use LIBRARY_PATH instead of setting LDFLAGS, which works with gcc 4.2
or newer, probably much older too, but only clang 3.0 or newer (again,
I think). I find no good flags such as -isystem to do libraries in
this way. - MLD
On Sat, Nov 9, 2013, at 04:53 PM, Ryan Schmidt wrote:
On Nov 9, 2013, at 14:00, Michael Dickens wrote:
Hi Mojca - Since the CMake PortGroup was recently modified to include
CPPFLAGS=-I${prefix}/include, I've been having to remove that setting
from my ports which use this group because it grabs already-installed
headers instead of those local to the port (CPPFLAGS gets propagated to
CFLAGS and CXXFLAGS).
[1]https://trac.macports.org/ticket/40656 should fix this.
Ditto for LDFLAGS and -L${prefix}/lib.
But not this. I'm not aware of a similar directive we could use to fix
this for libraries.
References
1. https://trac.macports.org/ticket/40656
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: redefined data types in different packages - request for help
On Nov 9, 2013, at 20:19, Michael Dickens wrote:
Using -isystem ${prefix}/include seems like a great solution to using
CPATH; it seems to work all the way back to clang 2.9 and gcc 4.2, maybe
further, while CPATH started with (I think) clang 2.9 -- I'll have to
investigate using it for qt4-mac.
I use LIBRARY_PATH instead of setting LDFLAGS, which works with gcc 4.2 or
newer, probably much older too, but only clang 3.0 or newer (again, I think).
I find no good flags such as -isystem to do libraries in this way. - MLD
MacPorts does already automatically set CPATH and LIBRARY_PATH for all ports in
all phases. Not sure this was a good thing to have done since it’s not
necessary when CPPFLAGS and LDFLAGS are set correctly, and you still need to
set CPPFLAGS and LDFLAGS correctly for older compilers that don’t understand
CPATH and LIBRARY_PATH.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: redefined data types in different packages - request for help
On Sat, Nov 9, 2013 at 9:00 PM, Michael Dickens wrote:
Hi Mojca - Since the CMake PortGroup was recently modified to include
CPPFLAGS=-I${prefix}/include, I've been having to remove that setting
from my ports which use this group because it grabs already-installed
headers instead of those local to the port (CPPFLAGS gets propagated to
CFLAGS and CXXFLAGS). Ditto for LDFLAGS and -L${prefix}/lib. Maybe
this change will help?
I don't see/understand the connection. To me this somehow resembles
badly written code, rather than inclusion of the wrong headers.
Ryan just pointed out a related ticket:
https://trac.macports.org/ticket/38168
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
