Re: [144442] trunk/dports/aqua/qt5

[Craig Treleaven]

> On Jan 8, 2016, at 6:50 PM, mcalh...@macports.org wrote:
> 
> Revision
> 12 Author
> mcalh...@macports.org Date
> 2016-01-08 15:50:05 -0800 (Fri, 08 Jan 2016)
> Log Message
> 
> qt5-qtbase: respect macosx_deployment_target and configure.cxx_stdlib values 
> in build
> Modified Paths
> 
> trunk/dports/aqua/qt5/Portfile 
> Added Paths
> 
> trunk/dports/aqua/qt5/files/patch-mkspecs.diff 
> Hi:

I take it this change caused qt5-qtwebkit (and others) to fail to build?

https://build.macports.org/builders/buildports-yosemite-x86_64/builds/7308/steps/status/logs/portstatus
 


Do you have an ETA for a fix?  I’m tyring to work on a new version of MythTV 
and need this.

Thanks,

Craig

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144442] trunk/dports/aqua/qt5

[Marcus Calhoun-Lopez]

r15 (https://trac.macports.org/changeset/15) is the change that broke 
things.
Hopefully, it is fixed in r144467 (https://trac.macports.org/changeset/144467).

Sorry for the inconvenience.

-Marcus


> On Jan 9, 2016, at 8:25 AM, Craig Treleaven  wrote:
> 
>> On Jan 8, 2016, at 6:50 PM, mcalh...@macports.org 
>>  wrote:
>> 
>> Revision
>> 12 Author
>> mcalh...@macports.org Date
>> 2016-01-08 15:50:05 -0800 (Fri, 08 Jan 2016)
>> Log Message
>> 
>> qt5-qtbase: respect macosx_deployment_target and configure.cxx_stdlib values 
>> in build
>> Modified Paths
>> 
>> trunk/dports/aqua/qt5/Portfile 
>> Added Paths
>> 
>> trunk/dports/aqua/qt5/files/patch-mkspecs.diff 
>> Hi:
> 
> I take it this change caused qt5-qtwebkit (and others) to fail to build?
> 
> https://build.macports.org/builders/buildports-yosemite-x86_64/builds/7308/steps/status/logs/portstatus
>  
> 
> 
> Do you have an ETA for a fix?  I’m tyring to work on a new version of MythTV 
> and need this.
> 
> Thanks,
> 
> Craig

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

OSX 10.11 buildbot status ?

[Chris Jones]

Hi,

Just curious, but whats the status of getting a buildbot for 10.11 set up ? 
Would be good to start proving binary tarballs for this platform.

Cheers chris
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144442] trunk/dports/aqua/qt5

[Craig Treleaven]

Thanks for the quick followup.  That got me going on Yosemite although I see 
the buildbots aren’t too happy.  ;)

Craig

> On Jan 9, 2016, at 12:22 PM, Marcus Calhoun-Lopez  
> wrote:
> 
> r15 (https://trac.macports.org/changeset/15 
> ) is the change that broke things.
> Hopefully, it is fixed in r144467 (https://trac.macports.org/changeset/144467 
> ).
> 
> Sorry for the inconvenience.
> 
> -Marcus
> 
> 
>> On Jan 9, 2016, at 8:25 AM, Craig Treleaven > > wrote:
>> 
>>> On Jan 8, 2016, at 6:50 PM, mcalh...@macports.org 
>>>  wrote:
>>> 
>>> Revision
>>> 12 Author
>>> mcalh...@macports.org Date
>>> 2016-01-08 15:50:05 -0800 (Fri, 08 Jan 2016)
>>> Log Message
>>> 
>>> qt5-qtbase: respect macosx_deployment_target and configure.cxx_stdlib 
>>> values in build
>>> Modified Paths
>>> 
>>> trunk/dports/aqua/qt5/Portfile 
>>> Added Paths
>>> 
>>> trunk/dports/aqua/qt5/files/patch-mkspecs.diff 
>>> Hi:
>> 
>> I take it this change caused qt5-qtwebkit (and others) to fail to build?
>> 
>> https://build.macports.org/builders/buildports-yosemite-x86_64/builds/7308/steps/status/logs/portstatus
>>  
>> 
>> 
>> Do you have an ETA for a fix?  I’m tyring to work on a new version of MythTV 
>> and need this.
>> 
>> Thanks,
>> 
>> Craig
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Broken links detected...to ApplicationServices ?

[Craig Treleaven]

Hi:

I’m working on a new version of MythTV (0.28) and I’m stymied on the following. 
 Every program (23), and every library and filter (28) is reported by MacPorts 
to have a linking error similar to the following:

--->  Scanning binaries for linking errors
…
Incompatible library version: /opt/local/bin/mythavtest requires version 64.0.0 
or later, but 
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 provides version 1.0.0
DEBUG: Marking /opt/local/bin/mythavtest as broken

Web searches and whatnot have not turned up any promising leads so I beg the 
indulgence of those more experienced than I.  

I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools.  

Thanks for any suggestions or help,

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144336] trunk/dports/science/silo/Portfile

[David Strubbe]

Are you sure that is what this line meant? It is hard to believe that
ccache could be related to this error message of illegal syntax in a
Makefile. And, I just commented out the ccache line and the port seems to
work fine without that line, or with configure.ccache yes.

David

On Sat, Jan 9, 2016 at 2:31 AM, Ryan Schmidt 
wrote:

> On Jan 6, 2016, at 1:21 PM, dstru...@macports.org wrote:
> >
> > Revision
> > 144336
> > Author
> > dstru...@macports.org
> > Date
> > 2016-01-06 11:21:10 -0800 (Wed, 06 Jan 2016)
> > Log Message
> >
> > silo: Use compilers portgroup for Fortran variants. Clarify meaning in
> description. Update livecheck. Remove irrelevant comment. Add caution about
> MPI with HDF5.
>
> Well, the comment was relevant in that it documented the error message one
> got when ccache was used, thus explaining why it had been disabled for this
> port.
>
> > Modified Paths
> >
> >   • trunk/dports/science/silo/Portfile
> > Diff
> >
> > Modified: trunk/dports/science/silo/Portfile (144335 => 144336)
>
> > -# Makefile:152: *** missing separator.  Stop.
> > +compilers.choosefc f77 f90
> > +compilers.setup
> > +
> >  configure.ccacheno
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144336] trunk/dports/science/silo/Portfile

[Ryan Schmidt]

On Jan 9, 2016, at 9:45 PM, David Strubbe wrote:

>>> On Sat, Jan 9, 2016 at 2:31 AM, Ryan Schmidt wrote:
> 
>> On Jan 6, 2016, at 1:21 PM, dstru...@macports.org wrote:
>> >
>> > Revision
>> > 144336
>> > Author
>> > dstru...@macports.org
>> > Date
>> > 2016-01-06 11:21:10 -0800 (Wed, 06 Jan 2016)
>> > Log Message
>> >
>> > silo: Use compilers portgroup for Fortran variants. Clarify meaning in 
>> > description. Update livecheck. Remove irrelevant comment. Add caution 
>> > about MPI with HDF5.
>> 
>> Well, the comment was relevant in that it documented the error message one 
>> got when ccache was used, thus explaining why it had been disabled for this 
>> port.
>> 
>> > Modified Paths
>> >
>> >   • trunk/dports/science/silo/Portfile
>> > Diff
>> >
>> > Modified: trunk/dports/science/silo/Portfile (144335 => 144336)
>> 
>> > -# Makefile:152: *** missing separator.  Stop.
>> > +compilers.choosefc f77 f90
>> > +compilers.setup
>> > +
>> >  configure.ccacheno
> 

> Are you sure that is what this line meant? It is hard to believe that ccache 
> could be related to this error message of illegal syntax in a Makefile. And, 
> I just commented out the ccache line and the port seems to work fine without 
> that line, or with configure.ccache yes.

Yes I'm sure, in that I put it there when I initially added the port in 
https://trac.macports.org/changeset/78261 and I mentioned it in 
https://trac.macports.org/ticket/29325#comment:4.


I just now backdated the port to that revision, re-enabled ccache and changed 
"hdf5-18" to "hdf5", and verified that silo 4.8 did have this problem. Lines 
151-152 of the Makefile ended up as:

CC_FULLPATH = /opt/local/bin/ccache
/usr/bin/clang

and later in the same file:

CXX_FULLPATH = /opt/local/bin/ccache
/usr/bin/clang++

In other words, the MacPorts-provided CC and CXX values "ccache /usr/bin/clang" 
and "ccache /usr/bin/clang++" were erroneously expanded and corrupted.


Now, in silo 4.10.2, if I re-enable ccache, the corresponding lines of Makefile 
read:

CC_FULLPATH = /opt/local/bin/ccache

and:

CXX_FULLPATH = /opt/local/bin/ccache

This is still wrong -- these variables are evidently meant to be the absolute 
paths to the compilers, but they have instead been computed as the absolute 
path to ccache -- but at least they've fixed things to use only the first word. 
It looks like the only places these variables are used is to show a summary at 
the end of the configure phase:

Compiling Options:
 C Compiler /opt/local/bin/ccache
   CPPFLAGS -I/opt/local -I/opt/local/include
 CFLAGS -pipe -Os -arch x86_64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wdeclaration-after-statement
LDFLAGS -L/opt/local/lib 
-Wl,-headerpad_max_install_names -arch x86_64
   LIBS -lhdf5  
Languages:
   C++ Compiler /opt/local/bin/ccache
   CXXFLAGS -pipe -Os -stdlib=libc++ -arch x86_64
   Fortran Compiler 
FCFLAGS -pipe -Os -m64
 FCLIBS 

And the same information gets written to the installed file 
/opt/local/lib/libsiloh5.settings as well.

It should probably be changed to directly use the unmodified values of CC and 
CXX and not attempt the error-prone process of trying to expand them into an 
absolute path, especially since it seems to serve no purpose other than to be 
informational to the user. Then ccache support for this portfile can be 
reenabled.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Broken links detected...to ApplicationServices ?

[Ryan Schmidt]

On Jan 9, 2016, at 9:33 PM, Craig Treleaven wrote:

> I’m working on a new version of MythTV (0.28) and I’m stymied on the 
> following.  Every program (23), and every library and filter (28) is reported 
> by MacPorts to have a linking error similar to the following:
> 
> --->  Scanning binaries for linking errors
> …
> Incompatible library version: /opt/local/bin/mythavtest requires version 
> 64.0.0 or later, but 
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>  provides version 1.0.0
> DEBUG: Marking /opt/local/bin/mythavtest as broken
> 
> Web searches and whatnot have not turned up any promising leads so I beg the 
> indulgence of those more experienced than I.  
> 
> I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools.  

What do you get when you run:

otool -L 
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 

On my 10.10 and 10.11 systems, the first two lines are:

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices:

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 (compatibility version 1.0.0, current version 48.0.0)

So, the OS provides ApplicationServices version 48.0.0 which is 
backward-compatible with 1.0.0. I'm not sure where you would have encountered a 
version 64.0.0 of ApplicationServices; it doesn't appear Apple has released any 
version that high yet.

Also, what do you get when you run:

otool -L /opt/local/bin/mythavtest

Maybe you have DYLD_LIBRARY_PATH set to a value that is causing the wrong 
libraries to be used.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: OSX 10.11 buildbot status ?

[Ryan Schmidt]

On Jan 9, 2016, at 12:28 PM, Chris Jones wrote:

> Just curious, but whats the status of getting a buildbot for 10.11 set up ? 
> Would be good to start proving binary tarballs for this platform.

Yes, that would be good! The status is here:

https://trac.macports.org/ticket/48609


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev