Re: Compile/Link 101
On Oct 5, 2013, at 18:13, Craig Treleaven wrote:
> At 4:06 PM -0500 10/5/13, Ryan Schmidt wrote:
>> >>> My somewhat hazy recollection is that it might have started working in
> 4.4. Unfortunately I don't have that version handy to check.
>>
>> http://trac.macports.org/ticket/36339#comment:3 says 4.4.1's clang doesn't
>> support LIBRARY_PATH either. 4.5's does. So since the build system is so
>> finicky you can blacklist macports-clang-2.9 macports-clang-3.0 and {clang <
>> 421}
>
> Thanks Ryan. I'll have a go at that.
>
> BTW, version information w.r.t. XCode 4.4 and 4.4.1 seems to be absent from
> the wiki page. Anyone have to details?
>
> https://trac.macports.org/wiki/XcodeVersionInfo
Someone would have to download those versions of Xcode and their corresponding
command line tools, install them, and get the requested info.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compile/Link 101
At 4:06 PM -0500 10/5/13, Ryan Schmidt wrote:
>>> My somewhat hazy recollection is that it might have started working in
4.4. Unfortunately I don't have that version handy to check.
http://trac.macports.org/ticket/36339#comment:3 says 4.4.1's clang
doesn't support LIBRARY_PATH either. 4.5's does. So since the build
system is so finicky you can blacklist macports-clang-2.9
macports-clang-3.0 and {clang < 421}
Thanks Ryan. I'll have a go at that.
BTW, version information w.r.t. XCode 4.4 and 4.4.1 seems to be
absent from the wiki page. Anyone have to details?
https://trac.macports.org/wiki/XcodeVersionInfo
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compile/Link 101
>>> My somewhat hazy recollection is that it might have started working in
>>> 4.4. Unfortunately I don't have that version handy to check.
http://trac.macports.org/ticket/36339#comment:3 says 4.4.1's clang doesn't
support LIBRARY_PATH either. 4.5's does. So since the build system is so
finicky you can blacklist macports-clang-2.9 macports-clang-3.0 and {clang <
421}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compile/Link 101
Sorry, I'd had a few different tabs open and must
have pasted the link from the wrong one.
I've bent Michael's ear on this before, but
Myth's build system is extremely hard for me to
follow particularly due to QMake. Different
platforms get different qmkspec files--which are
actually a chain of nested include files
sometimes overriding each other. I asked about
this case because none of that was involved...and
I still didn't understand why XCode 5.0 succeeded
and XCode 4.3 failed. At least now, I've got a
clue.
OTOH, I checked the clang man page under XCode 5
and it still doesn't mention the LIBRARY_PATH
environment variable.
Craig
At 3:27 PM -0400 10/5/13, Michael Dickens wrote:
I think Craig is referring to the comment within the Portfile for
qt4-mac, about 2/5 of the way down under "Block various compilers".
MacPorts' build of Qt4 requires the use of CPATH and LIBRARY_PATH, and
post-configure I remove any -I${prefix}/lib entries to keep them from
appearing at inappropriate ordering during the build stage. So, I
blacklist all known compilers with this issue; it's the compiler that
makes the difference, much more than the version of XCode (though they
are related). And, during configuration Qt4 checks this property too. I
think MythTV doesn't do path ordering carefully, but it's been a bit
since I looked at that project. - MLD
On Sat, Oct 5, 2013, at 03:09 PM, Joshua Root wrote:
On 2013-10-6 00:53 , Craig Treleaven wrote:
> At 11:03 PM -0400 10/4/13, Lawrence Velázquez wrote:
>> MacPorts sets the LIBRARY_PATH environment variable in the configure
>> phase, which sufficiently recent compilers take into account when
>> linking. I don't know exactly when Clang started respecting it.
>
> Thank you! From some searching, I found a bug report [1] for Qt4-mac
> related to this problem. One comment suggested that XCode >= 4.5 and
> clang >= 3.1 will respect LIBRARY_PATH. Can someone confirm?
>
> [1] https://trac.macports.org/ticket/37878
To which comment are you referring? AFAICT, all that ticket says
regarding Xcode versions supporting LIBRARY_PATH is that it doesn't work
with 4.3.3.
My somewhat hazy recollection is that it might have started working in
4.4. Unfortunately I don't have that version handy to check.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compile/Link 101
I think Craig is referring to the comment within the Portfile for
qt4-mac, about 2/5 of the way down under "Block various compilers".
MacPorts' build of Qt4 requires the use of CPATH and LIBRARY_PATH, and
post-configure I remove any -I${prefix}/lib entries to keep them from
appearing at inappropriate ordering during the build stage. So, I
blacklist all known compilers with this issue; it's the compiler that
makes the difference, much more than the version of XCode (though they
are related). And, during configuration Qt4 checks this property too. I
think MythTV doesn't do path ordering carefully, but it's been a bit
since I looked at that project. - MLD
On Sat, Oct 5, 2013, at 03:09 PM, Joshua Root wrote:
On 2013-10-6 00:53 , Craig Treleaven wrote:
At 11:03 PM -0400 10/4/13, Lawrence Velázquez wrote:
MacPorts sets the LIBRARY_PATH environment variable in the configure
phase, which sufficiently recent compilers take into account when
linking. I don't know exactly when Clang started respecting it.
Thank you! From some searching, I found a bug report [1] for
Qt4-mac
related to this problem. One comment suggested that XCode >= 4.5 and
clang >= 3.1 will respect LIBRARY_PATH. Can someone confirm?
[1] https://trac.macports.org/ticket/37878
To which comment are you referring? AFAICT, all that ticket says
regarding Xcode versions supporting LIBRARY_PATH is that it doesn't
work
with 4.3.3.
My somewhat hazy recollection is that it might have started working
in
4.4. Unfortunately I don't have that version handy to check.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compile/Link 101
On 2013-10-6 00:53 , Craig Treleaven wrote: > At 11:03 PM -0400 10/4/13, Lawrence Velázquez wrote: >> MacPorts sets the LIBRARY_PATH environment variable in the configure >> phase, which sufficiently recent compilers take into account when >> linking. I don't know exactly when Clang started respecting it. > > Thank you! From some searching, I found a bug report [1] for Qt4-mac > related to this problem. One comment suggested that XCode >= 4.5 and > clang >= 3.1 will respect LIBRARY_PATH. Can someone confirm? > > [1] https://trac.macports.org/ticket/37878 To which comment are you referring? AFAICT, all that ticket says regarding Xcode versions supporting LIBRARY_PATH is that it doesn't work with 4.3.3. My somewhat hazy recollection is that it might have started working in 4.4. Unfortunately I don't have that version handy to check. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compile/Link 101
On 2013-10-6 00:53 , Craig Treleaven wrote: > BTW, I realize I could set a -L flag in LDFLAGS but Myth includes > modified versions of FFMPEG, dvdnav and a few other libraries. The > contents of LDFLAGS gets included early in the link line and therefore > will try to link against any MacPorts-installed versions of these > libraries. Not surprisingly, that never works out well. ;) This usually counts as a bug in the build system. The LDFLAGS from the configure environment need to go after any -L flags for internal libs. (Same deal for CPPFLAGS and -I flags for internal include dirs.) - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [111903] trunk/dports/kde
On Oct 5, 2013, at 09:13, ni...@macports.org wrote:
> Revision: 111903
> https://trac.macports.org/changeset/111903
> Author: ni...@macports.org
> Date: 2013-10-05 07:13:57 -0700 (Sat, 05 Oct 2013)
> Log Message:
> ---
> kdeedu ports: update to 4.11.2
> Modified: trunk/dports/kde/rocs/Portfile
> +#Clang of XCode 5 presently fails with a boost error
> +#(fatal error: recursive template instantiation exceeded maximum depth of
> 128)
> +#XCode 5.0.0 is 500.2.75
> +compiler.blacklist {clang > 500}
We recently fixed this same error in vigra using:
configure.cxxflags-append -ftemplate-depth-1024
Maybe something similar will help rocs.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compile/Link 101
At 11:03 PM -0400 10/4/13, Lawrence Velázquez wrote: On Oct 4, 2013, at 9:39 PM, Craig Treleaven wrote: I actually don't know how the test _can succeed_ with XCode 5? There is no '-L' flag to indicate that the library is under /opt/local/lib. MacPorts sets the LIBRARY_PATH environment variable in the configure phase, which sufficiently recent compilers take into account when linking. I don't know exactly when Clang started respecting it. Thank you! From some searching, I found a bug report [1] for Qt4-mac related to this problem. One comment suggested that XCode >= 4.5 and clang >= 3.1 will respect LIBRARY_PATH. Can someone confirm? [1] https://trac.macports.org/ticket/37878 BTW, I realize I could set a -L flag in LDFLAGS but Myth includes modified versions of FFMPEG, dvdnav and a few other libraries. The contents of LDFLAGS gets included early in the link line and therefore will try to link against any MacPorts-installed versions of these libraries. Not surprisingly, that never works out well. ;) Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New wiki page describing commit rules needed or nonsense?
On 2013-10-04 20:00, mk-macpo...@techno.ms wrote: > I figured that a section about rules concerning properly formatted commit > messages are missing in the wiki (not to talk about the Guide), which is why > I created the following page: > > https://trac.macports.org/wiki/CommitRules > > below the committers guide > > https://trac.macports.org/wiki/CommittersGuide > > In case I am mistaken and the information is already present, but hidden > someplace else, please let me know. We have point 8. there, "Commit messages should make clear what has been changed": https://trac.macports.org/wiki/NewCommittersGuide#PortCommitterResponsibilities I added a link to the new wiki page there as well. We could now probably remove the three points below that as they are covered in the new wiki page. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
