mac: In component builds, link against libc++.

mac: In component builds, link against libc++.

Using libc++ this way requires OS X 10.7, but for component builds
that's ok.  (It's a developer-only config, we require, 10.8 for building
already, and moving a component build to a 10.6 box for testing is
very difficult already – so people testing stuff on 10.6 will do so with
static library builds.)

Since the deployment target is still 10.6, Xcode's clang would complain
that libc++ requires 10.7 while the deployment target asks for 10.6.
Open-source clang (and hence Chromium's clang) doesn't complain
about this. (We haven't used Xcode's clang on Mac in 4 years.)

For static library builds we'll have to do something else. I have a plan,
but that's for a separate CL.

I tried doing this change in gn too, but the gn/mac build is currently so
broken that `gn gen` errors out on me without any local changes. I'll port
this to gn in a follow-up.

BUG=400091
R=mark@chromium.org

Committed: https://crrev.com/f0fa84cdd8a2037059bec96df1bf6eb3d533ebf9
Cr-Commit-Position: refs/heads/master@{#354646}

[Nico, 2015-10-16 22:31:25]

thakis@chromium.org changed reviewers:
+ mark@chromium.org

[Nico, 2015-10-16 22:31:26]

This part was easier than expected.

[Mark Mentovai, 2015-10-16 22:34:59]

https://codereview.chromium.org/1408263002/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/1408263002/diff/1/build/common.gypi#newcode5307
build/common.gypi:5307: 'OTHER_LDFLAGS': [ '-lc++' ],
I thought CLANG_CXX_LIBRARY would have been enough. Is it not? What does the
link line look like now? I don’t want to wind up with something like -lc++
-lstdc++.

[Nico, 2015-10-16 23:08:35]

https://codereview.chromium.org/1408263002/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/1408263002/diff/1/build/common.gypi#newcode5307
build/common.gypi:5307: 'OTHER_LDFLAGS': [ '-lc++' ],
Excellent question! I thought it wasn't enough because we pass
-mmin-macosx-version=10.6, but it turns out I screwed up my local testing and
this isn't needed. Done.

[Mark Mentovai, 2015-10-16 23:09:30]

Yes, this makes much more sense, now. LGTM!

[Nico, 2015-10-16 23:10:39]

Hm, works locally but one of the bot complains: FAILED: /b/build/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang -Wl,-search_paths_first
-Wl,-pie -lc++ -mmacosx-version-min=10.6 -isysroot
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
-arch x86_64 -L. -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../..
-stdlib=libc++ -o tls_edit
obj/native_client/src/tools/tls_edit/tls_edit.tls_edit.o libplatform.a
librdfa_validator.a libgio.a   && (export
BUILT_PRODUCTS_DIR=/b/build/slave/mac/build/src/out/Debug; export
CONFIGURATION=Debug; export EXECUTABLE_NAME=tls_edit; export
EXECUTABLE_PATH=tls_edit; export FULL_PRODUCT_NAME=tls_edit; export
PRODUCT_NAME=tls_edit; export PRODUCT_TYPE=com.apple.product-type.tool; export
SDKROOT=/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk;
export
SRCROOT=/b/build/slave/mac/build/src/out/Debug/../../native_client/src/tools/tls_edit;
export SOURCE_ROOT="${SRCROOT}"; export
TARGET_BUILD_DIR=/b/build/slave/mac/build/src/out/Debug; export
TEMP_DIR="${TMPDIR}"; (cd ../../native_client/src/tools/tls_edit &&
../../../../build/mac/change_mach_o_flags_from_xcode.sh); G=$?; ((exit $G) || rm
-rf tls_edit) && exit $G)

ld: library not found for -lc++

Maybe this requires some minimum Xcode version (that bot still has 5.1.1
apparently). I'll look around some.

[Mark Mentovai, 2015-10-16 23:21:11]

> ld: library not found for -lc++

Well that looks like the right -l.

> -Wl,-pie -lc++ -mmacosx-version-min=10.6 -isysroot
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk

Oh, there’s the problem. How are there still stragglers on that SDK?

[Mark Mentovai, 2015-10-16 23:21:42]

> ld: library not found for -lc++

Well that looks like the right -l.

> -Wl,-pie -lc++ -mmacosx-version-min=10.6 -isysroot
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk

Oh, there’s the problem. How are there still stragglers on that SDK?

[Mark Mentovai, 2015-10-16 23:22:02]

working from airplane = double messages

[Nico, 2015-10-16 23:25:10]

On Fri, Oct 16, 2015 at 4:21 PM, <mark@chromium.org> wrote:

> ld: library not found for -lc++
>>
>
> Well that looks like the right -l.
>
> -Wl,-pie -lc++ -mmacosx-version-min=10.6 -isysroot
>>
>
>
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
>
> Oh, there’s the problem. How are there still stragglers on that SDK?


The new try run looks better. The 10.6 SDK isn't supposed to work anymore
anyhow, so I guess I'll just file a bug for that bot. (How does this even
make it into sysroot? I thought find_sdk.py should throw if it doesn't find
a new enough SDK. Strange.)

Anyhoo, I'll file a bug and land this CL.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2015-10-16 23:28:10]

On 2015/10/16 23:25:10, Nico wrote:
> On Fri, Oct 16, 2015 at 4:21 PM, <mailto:mark@chromium.org> wrote:
> 
> > ld: library not found for -lc++
> >>
> >
> > Well that looks like the right -l.
> >
> > -Wl,-pie -lc++ -mmacosx-version-min=10.6 -isysroot
> >>
> >
> >
>
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
> >
> > Oh, there’s the problem. How are there still stragglers on that SDK?
> 
> 
> The new try run looks better. The 10.6 SDK isn't supposed to work anymore
> anyhow, so I guess I'll just file a bug for that bot. (How does this even
> make it into sysroot? I thought find_sdk.py should throw if it doesn't find
> a new enough SDK. Strange.)
> 
> Anyhoo, I'll file a bug

https://code.google.com/p/chromium/issues/detail?id=544325

[Nico, 2015-10-16 23:33:19]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2015-10-16 23:33:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1408263002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1408263002/20001

[Nico, 2015-10-17 00:04:37]

Committed patchset #2 (id:20001) to pending queue manually as
d33705e585f51a687969ffcb9977b5c2c955bb53 (presubmit successful).

[commit-bot: I haz the power, 2015-10-17 00:05:09]

Patchset 2 (id:??) landed as
https://crrev.com/f0fa84cdd8a2037059bec96df1bf6eb3d533ebf9
Cr-Commit-Position: refs/heads/master@{#354646}

[boliu, 2015-10-17 15:12:45]

I think this is causing compile failures on mac_chromium_compile_dbg_ng, but
only on some patches it seems. cq is blocking those patches.

http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...

FAILED: /b/build/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang++ -bundle
-Wl,-search_paths_first -Wl,-ObjC -mmacosx-version-min=10.6 -isysroot
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
-arch i386 -L. -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../..
-stdlib=libc++ -o arch/libremoting_host_prefpane.i386.prefPane
@remoting_host_prefpane.prefPane.i386.rsp
Undefined symbols for architecture i386:
  "std::__1::basic_istream<char, std::__1::char_traits<char> >&
std::__1::getline<char, std::__1::char_traits<char>, std::__1::allocator<char>
>(std::__1::basic_istream<char, std::__1::char_traits<char> >&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >&, char)", referenced from:
      Json::Reader::parse(std::__1::basic_istream<char,
std::__1::char_traits<char> >&, Json::Value&, bool) in
remoting_host_prefpane.json_reader.i386.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

[Nico, 2015-10-17 18:54:42]

Thanks, filed https://code.google.com/p/chromium/issues/detail?id=544531
for that.

On Sat, Oct 17, 2015 at 8:12 AM, <boliu@chromium.org> wrote:

> I think this is causing compile failures on mac_chromium_compile_dbg_ng,
> but
> only on some patches it seems. cq is blocking those patches.
>
>
>
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...
>
> FAILED: /b/build/goma/gomacc
> ../../third_party/llvm-build/Release+Asserts/bin/clang++ -bundle
> -Wl,-search_paths_first -Wl,-ObjC -mmacosx-version-min=10.6 -isysroot
>
>
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
> -arch i386 -L. -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../..
> -stdlib=libc++ -o arch/libremoting_host_prefpane.i386.prefPane
> @remoting_host_prefpane.prefPane.i386.rsp
> Undefined symbols for architecture i386:
>   "std::__1::basic_istream<char, std::__1::char_traits<char> >&
> std::__1::getline<char, std::__1::char_traits<char>,
> std::__1::allocator<char>
>
>> (std::__1::basic_istream<char, std::__1::char_traits<char> >&,
>>
> std::__1::basic_string<char, std::__1::char_traits<char>,
> std::__1::allocator<char> >&, char)", referenced from:
>       Json::Reader::parse(std::__1::basic_istream<char,
> std::__1::char_traits<char> >&, Json::Value&, bool) in
> remoting_host_prefpane.json_reader.i386.o
> ld: symbol(s) not found for architecture i386
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ninja: build stopped: subcommand failed.
>
> https://codereview.chromium.org/1408263002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2015-10-17 19:15:06]

Workaround to heal the bots: https://codereview.chromium.org/1410263002/

On Sat, Oct 17, 2015 at 11:54 AM, Nico Weber <thakis@chromium.org> wrote:

> Thanks, filed https://code.google.com/p/chromium/issues/detail?id=544531
> for that.
>
> On Sat, Oct 17, 2015 at 8:12 AM, <boliu@chromium.org> wrote:
>
>> I think this is causing compile failures on mac_chromium_compile_dbg_ng,
>> but
>> only on some patches it seems. cq is blocking those patches.
>>
>>
>>
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...
>>
>> FAILED: /b/build/goma/gomacc
>> ../../third_party/llvm-build/Release+Asserts/bin/clang++ -bundle
>> -Wl,-search_paths_first -Wl,-ObjC -mmacosx-version-min=10.6 -isysroot
>>
>>
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
>> -arch i386 -L. -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../..
>> -stdlib=libc++ -o arch/libremoting_host_prefpane.i386.prefPane
>> @remoting_host_prefpane.prefPane.i386.rsp
>> Undefined symbols for architecture i386:
>>   "std::__1::basic_istream<char, std::__1::char_traits<char> >&
>> std::__1::getline<char, std::__1::char_traits<char>,
>> std::__1::allocator<char>
>>
>>> (std::__1::basic_istream<char, std::__1::char_traits<char> >&,
>>>
>> std::__1::basic_string<char, std::__1::char_traits<char>,
>> std::__1::allocator<char> >&, char)", referenced from:
>>       Json::Reader::parse(std::__1::basic_istream<char,
>> std::__1::char_traits<char> >&, Json::Value&, bool) in
>> remoting_host_prefpane.json_reader.i386.o
>> ld: symbol(s) not found for architecture i386
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> ninja: build stopped: subcommand failed.
>>
>> https://codereview.chromium.org/1408263002/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.