Re: Passing '-arch pcc' to gfortran-mp-4.8: unrecognized command line option
On 11/09/2013 10:16 PM, Joshua Root wrote: On 2013-11-10 08:27 , Blair Zajac wrote: I noticed my PPC MacPorts version was out of date so updated it to 2.2.1. After this, there was an octave-devel update which failed to compile while the previous version did. Looking at config.log, I'm seeing this: configure:33534: checking how to get verbose linking output from /opt/local/bin/gfortran-mp-4.8 configure:33544: /opt/local/bin/gfortran-mp-4.8 -c -pipe -Os -m32 conftest.f >&5 configure:33544: $? = 0 configure:33562: /opt/local/bin/gfortran-mp-4.8 -o conftest -pipe -Os -m32 -v -arch ppc conftest.f -lm Using built-in specs. gfortran-mp-4.8: error: unrecognized command line option '-arch' Target: ppc-apple-darwin9 Thread model: posix gcc version 4.8.2 (MacPorts gcc48 4.8.2_0) Given that 10.5 and PPC is pretty old, is it possible that the updates to portconfigure.tcl don't handle PPC as it used to? If you look in main.log at the environment that's being set when calling configure you should be able to see whether base is doing anything wrong there. It looks more like this configure check is picking up -arch ppc from somewhere it shouldn't. Maybe CFLAGS, but only if it's also stripping out duplicate flags like -Os that would be there if it was using e.g. $F90FLAGS -v $CFLAGS. The -m32 as also seen in the previous line is part of the correct fortran flags. 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? 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' Blair ___ 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 08:27 , Blair Zajac wrote: > I noticed my PPC MacPorts version was out of date so updated it to > 2.2.1. After this, there was an octave-devel update which failed to > compile while the previous version did. Looking at config.log, I'm > seeing this: > > > configure:33534: checking how to get verbose linking output from > /opt/local/bin/gfortran-mp-4.8 > configure:33544: /opt/local/bin/gfortran-mp-4.8 -c -pipe -Os -m32 > conftest.f >&5 > configure:33544: $? = 0 > configure:33562: /opt/local/bin/gfortran-mp-4.8 -o conftest -pipe -Os > -m32 -v -arch ppc conftest.f -lm > Using built-in specs. > gfortran-mp-4.8: error: unrecognized command line option '-arch' > Target: ppc-apple-darwin9 > Thread model: posix > gcc version 4.8.2 (MacPorts gcc48 4.8.2_0) > > > Given that 10.5 and PPC is pretty old, is it possible that the updates > to portconfigure.tcl don't handle PPC as it used to? If you look in main.log at the environment that's being set when calling configure you should be able to see whether base is doing anything wrong there. It looks more like this configure check is picking up -arch ppc from somewhere it shouldn't. Maybe CFLAGS, but only if it's also stripping out duplicate flags like -Os that would be there if it was using e.g. $F90FLAGS -v $CFLAGS. The -m32 as also seen in the previous line is part of the correct fortran flags. - 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 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. - Josh ___ 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
Re: [113128] trunk/dports/multimedia
At 8:57 PM -0600 11/9/13, Ryan Schmidt wrote: On Nov 9, 2013, at 17:29, pixi...@macports.org wrote: Revision 113128 Author pixi...@macports.org Date 2013-11-09 15:29:02 -0800 (Sat, 09 Nov 2013) Log Message multimedia/mythtv-core.27: - New port. --- trunk/dports/multimedia/mythtv-core.27/files/Myth_Frontend.applescript (rev 0) +++ trunk/dports/multimedia/mythtv-core.27/files/Myth_Frontend.applescript 2013-11-09 23:29:02 UTC (rev 113128) @@ -0,0 +1,38 @@ +(* Applescript to run 'Unix' version of mythfronted +For use with MacPorts install of Myth +Author: Craig Treleaven, ctreleaven at cogeco.ca +Version: 0.27.0 +Modified: 2012May15 + 2012Nov20 -- handle 'thread not shut down error' on exit, add --quiet to prevent +console output from being returned to AppleScript, allow experimental AirPlay + 2013Sep25 -- revert logserver stuff, remove AirPlay setting that is now unnecessary + +*) +property MFEappPath : "/opt/local/bin/mythfrontend" You shouldn't assume the prefix is /opt/local. Not sure how that one crept in...I'll get a revision put through. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [113128] trunk/dports/multimedia
On Nov 9, 2013, at 17:29, pixi...@macports.org wrote: > Revision > 113128 > Author > pixi...@macports.org > Date > 2013-11-09 15:29:02 -0800 (Sat, 09 Nov 2013) > Log Message > > multimedia/mythtv-core.27: > - New port. > --- trunk/dports/multimedia/mythtv-core.27/files/Myth_Frontend.applescript > (rev 0) > +++ trunk/dports/multimedia/mythtv-core.27/files/Myth_Frontend.applescript > 2013-11-09 23:29:02 UTC (rev 113128) > > @@ -0,0 +1,38 @@ > > +(* Applescript to run 'Unix' version of mythfronted > +For use with MacPorts install of Myth > +Author: Craig Treleaven, ctreleaven at > cogeco.ca > > +Version: 0.27.0 > +Modified: 2012May15 > + 2012Nov20 -- handle 'thread not shut down error' on exit, add > --quiet to prevent > +console output from being returned to AppleScript, allow > experimental AirPlay > + 2013Sep25 -- revert logserver stuff, remove AirPlay setting that > is now unnecessary > + > +*) > +property MFEappPath : "/opt/local/bin/mythfrontend” You shouldn’t assume the prefix is /opt/local. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 9, 2013, at 12:35, Craig Treleaven wrote: > My port uses p5.12-libwww-perl which relies on a list of other perl modules. You should actually declare dependencies on the specific other modules that you use, not libwww-perl itself anymore. $ port notes p5-libwww-perl p5-libwww-perl has the following notes: As of version 6.00, libwww-perl has been broken up into multiple packages. If you were using p5-libwww-perl for just one or two of its modules before, you may be able to pare down your installation to just those modules now. Other important changes have been made that may affect your code; for details, please see: /opt/local/share/doc/p5-libwww-perl/Changes ___ 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
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 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: Passing '-arch pcc' to gfortran-mp-4.8: unrecognized command line option
On Nov 9, 2013, at 15:27, Blair Zajac wrote: > > I noticed my PPC MacPorts version was out of date so updated it to 2.2.1. > After this, there was an octave-devel update which failed to compile while > the previous version did. Looking at config.log, I'm seeing this: > > > configure:33534: checking how to get verbose linking output from > /opt/local/bin/gfortran-mp-4.8 > configure:33544: /opt/local/bin/gfortran-mp-4.8 -c -pipe -Os -m32 conftest.f > >&5 > configure:33544: $? = 0 > configure:33562: /opt/local/bin/gfortran-mp-4.8 -o conftest -pipe -Os -m32 -v > -arch ppc conftest.f -lm > Using built-in specs. > gfortran-mp-4.8: error: unrecognized command line option '-arch' > Target: ppc-apple-darwin9 > Thread model: posix > gcc version 4.8.2 (MacPorts gcc48 4.8.2_0) > > > Given that 10.5 and PPC is pretty old, is it possible that the updates to > portconfigure.tcl don't handle PPC as it used to? I'm not aware of any recent changes in base with regard to arch handling. I'd rather blame the portfiles -- perhaps the fortran recipe that's in the wiki and has been much employed. Or perhaps a problem specific to the octave-devel port. Certainly passing arch flags to gfortran is wrong on any platform. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Passing '-arch pcc' to gfortran-mp-4.8: unrecognized command line option
I noticed my PPC MacPorts version was out of date so updated it to 2.2.1. After this, there was an octave-devel update which failed to compile while the previous version did. Looking at config.log, I'm seeing this: configure:33534: checking how to get verbose linking output from /opt/local/bin/gfortran-mp-4.8 configure:33544: /opt/local/bin/gfortran-mp-4.8 -c -pipe -Os -m32 conftest.f >&5 configure:33544: $? = 0 configure:33562: /opt/local/bin/gfortran-mp-4.8 -o conftest -pipe -Os -m32 -v -arch ppc conftest.f -lm Using built-in specs. gfortran-mp-4.8: error: unrecognized command line option '-arch' Target: ppc-apple-darwin9 Thread model: posix gcc version 4.8.2 (MacPorts gcc48 4.8.2_0) Given that 10.5 and PPC is pretty old, is it possible that the updates to portconfigure.tcl don't handle PPC as it used to? Thanks, Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Speaking of my script, I've made a bunch of changes to it recently, so I'll
probably need to create a new tag sometime so I can update the
`macportsscripts` port that points to it... The version from 0.1.4 still
reports library links that are there due to libtool overlinking, and I've
been working on finding ways to ignore those links, mainly by checking for
symbol usage with `nm`...
On Fri, Nov 8, 2013 at 10:34 PM, Craig Treleaven wrote:
> At 4:27 PM +0100 11/1/13, Clemens Lang wrote:
>
>> On Fri, Nov 01, 2013 at 10:27:04AM +1100, Joshua Root wrote:
>>
>>> If they are needed at build time and runtime, use depends_lib. If they
>>> are only needed at runtime, use depends_run.
>>>
>>
>> is there any difference between listing a package in both depends_build
>> and depends_run compared to just listing it in depends_lib, e.g. in how
>> licensing stuff propagates?
>>
>> Since MacPorts ensures depends_run dependencies are installed before
>> attempting to build a package, we usually do not notice a depends_run
>> dependency that should rather be depends_build.
>>
>> I'm currently trying to improve trace mode to a point where every
>> package I have installed builds fine using trace mode and I've come
>> across the gcc ports, which set
>> depends_run port:ld64 port:cctools
>> but fail to configure when trace mode (correctly) hides files installed
>> by these ports. I wonder whether the correct fix would be to convert
>> those into depends_lib, or just add them as depends_build, too.
>>
>
> I was playing with egall's port-depcheck.sh script:
>
> https://github.com/cooljeanius/macportsscripts/
> blob/v0.1.4/port-depcheck.sh
>
> It identified several interesting things in my MythTV ports that I hadn't
> known before--including a couple more opportunistic links (Myth is so
> promiscuous!).
>
> A couple of questions for the more-experienced here.
>
> Myth includes Perl and Python bindings that need a number of dependencies
> to work (eg port:${pymodver}-mysql, port:${perlmodver}-dbd-mysql, etc). I
> have these listed as depends_lib but no Myth binaries link directly to
> them. Is it advantageous to list them instead as depends_run?
>
> egall's script says that Myth does not link directly to
> qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac. Again, are
> there advantages to showing qt4-mac as a depends_lib but the plugin as a
> depends_run?
>
> I'm not a professional developer; just trying to understand a little more.
>
> Thanks,
>
> Craig
>
> ___
> 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: Questions on dependencies
On Nov 9, 2013, at 1:35 PM, Craig Treleaven wrote: > So, in a way, we all use depends_lib for certain things as a short-hand for > listing stuff as both depends_build and depends_run, no? That's the general usage, yes. > In a perfect world, maybe we should have a "depends_mod" for indicating a > dependency on an interpreted module (perl, python, php, ruby, ...)? It would > express the relationship more precisely, I think. OTOH, I don't see any > particular advantage other than that and it would be a tremendous amount of > work to got through all existing ports and split depends_mod out from > depends_lib as necessary. Perhaps just the documentation for depends_lib > should be expanded to say that it indicates both compiled and interpreted > linkages? That's what this whole conversation has been about: whether "depends_lib" can just be shorthand for "depends_build" + "depends_run", or whether it should specifically indicate linkage. vq ___ 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 wrote:
> On Sat, Nov 9, 2013 at 3:08 PM, Mojca Miklavec 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: Questions on dependencies
At 11:48 AM -0500 11/9/13, Jeremy Lavergne wrote:
Myth includes Perl and Python bindings that need a number of
dependencies to work (eg port:${pymodver}-mysql,
port:${perlmodver}-dbd-mysql, etc). I have these listed as
depends_lib but no Myth binaries link directly to them. Is it
advantageous to list them instead as depends_run?
The packages aren't guaranteed to be available during build time if
it's only a depends_run. You might need them listed in both
depends_build and depends_run, if the bindings aren't always built.
egall's script says that Myth does not link directly to
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac.
Again, are there advantages to showing qt4-mac as a depends_lib but
the plugin as a depends_run?
Again, qt4-mac should definitely be listed as depends_lib, but the
plugin might need both _run and _build.
Try setting the plugin dependency to _run and deactivate it, then
build and see if your package still uses it. If so, then the plugin
isn't needed during _build. If it doesn't work then you need it in
both _build and _run.
So, in a way, we all use depends_lib for certain things as a
short-hand for listing stuff as both depends_build and depends_run,
no? For example, I was looking at some of the perl modules. My port
uses p5.12-libwww-perl which relies on a list of other perl modules.
Using port-depcheck confirms that no compiled library links. Of the
rdeps for p5.12-libwww-perl, only a couple of lower level modules
appear to link directly to a compiled library, eg p5.12-net-ssleay.
In a perfect world, maybe we should have a "depends_mod" for
indicating a dependency on an interpreted module (perl, python, php,
ruby, ...)? It would express the relationship more precisely, I
think. OTOH, I don't see any particular advantage other than that
and it would be a tremendous amount of work to got through all
existing ports and split depends_mod out from depends_lib as
necessary. Perhaps just the documentation for depends_lib should be
expanded to say that it indicates both compiled and interpreted
linkages?
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Myth includes Perl and Python bindings that need a number of
dependencies to work (eg port:${pymodver}-mysql,
port:${perlmodver}-dbd-mysql, etc). I have these listed as depends_lib
but no Myth binaries link directly to them. Is it advantageous to list
them instead as depends_run?
The packages aren't guaranteed to be available during build time if it's
only a depends_run. You might need them listed in both depends_build and
depends_run, if the bindings aren't always built.
egall's script says that Myth does not link directly to
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac. Again,
are there advantages to showing qt4-mac as a depends_lib but the plugin
as a depends_run?
Again, qt4-mac should definitely be listed as depends_lib, but the plugin
might need both _run and _build.
Try setting the plugin dependency to _run and deactivate it, then build
and see if your package still uses it. If so, then the plugin isn't needed
during _build. If it doesn't work then you need it in both _build and _run.
___
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 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
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
