Re: Compile/Link 101
On Oct 5, 2013, at 16:59, Ryan Schmidt wrote:
>
> 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.
https://www.opensource.apple.com/release/developer-tools-44/
clang-421.0.57
llvmgcc42-2336.11
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: 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: 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: Compile/Link 101
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. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Compile/Link 101
Could someone please explain some very basic stuff about
compiling/linking C and C++ code? For a new version of Myth, the
configure script succeeds with XCode 5 on Mtn Lion and _fails_ with
XCode 4.3 on Lion. The bit that I'm looking at just tests whether
certain libraries (faac in this case) are installed and, if so,
enables additional features in the package. The 'config.ep' file
(btw, is that a Unix/Linux standard thingy?) shows how it tried to do
the test:
BEGIN
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
1 #include
2 #include
3 long check_faacEncGetVersion(void) { return (long) faacEncGetVersion; }
4 int main(void) { return 0; }
END
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
/usr/bin/clang -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_DARWIN_C_SOURCE -DPIC -pipe -std=c99
-fomit-frame-pointer -fPIC -c -o
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.CaP65ZOS.o
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
/usr/bin/clang -Wl,-dynamic,-search_paths_first -o
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.7NGrnBrt
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.CaP65ZOS.o
-lfaac -lm -lbz2 -lz
ld: library not found for -lfaac
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
ERROR: libfaac not found
faac _is_ installed:
MediaMini:~ mytthtv$ port installed |grep aac
faac @1.28_2 (active)
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.
I must be missing something obvious. Pointers to introductory
material gratefully accepted.
Craig
--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054 ctrelea...@cogeco.ca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
