Continue the last email,following the second method,I add a arm condition
branch in base/base.gypi,if the _toolset is "target" and the OS is Android,then
replace some .cc files with my own.The new link error comes:[16/31] SOLINK
lib/libxwalkcore.soFAILED: if [ ! -e lib/libxwalkcore.so -o ! -e
lib/libxwalkcore.so.TOC ]; then
/home/dachen/crosswalk-src/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
-shared -Wl,-z,now -Wl,-z,relro -Wl,--fatal-warnings -Wl,-z,defs
-Wl,-z,noexecstack -fPIC
-B/home/dachen/crosswalk-src/src/third_party/binutils/Linux_x64/Release/bin
-Wl,--no-fatal-warnings
-L/home/dachen/crosswalk-src/src/third_party/etf/etf_dynamics/android/libs/armeabi
-fuse-ld=gold -Wl,--no-undefined
--sysroot=../../third_party/android_tools/ndk//platforms/android-14/arch-arm
-nostdlib
-L../../third_party/android_tools/ndk//sources/cxx-stl/stlport/libs/armeabi-v7a
-Wl,--exclude-libs=libgcc.a -Wl,--exclude-libs=libstlport_static.a
-Wl,--exclude-libs=libcommon_audio.a -Wl,--exclude-libs=libcommon_audio_neon.a
-Wl,--exclude-libs=libcommon_audio_sse2.a -Wl,--exclude-libs=libiSACFix.a
-Wl,--exclude-libs=libisac_neon.a -Wl,--exclude-libs=libopus.a
-Wl,--exclude-libs=libvpx.a -Wl,--icf=safe -Wl,-shared,-Bsymbolic
../../third_party/android_tools/ndk//platforms/android-14/arch-arm/usr/lib/crtbegin_so.o
-Wl,--version-script=/home/dachen/crosswalk-src/src/build/android/android_no_jni_exports.lst
-Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--warn-shared-textrel -o
lib/libxwalkcore.so -Wl,-soname=libxwalkcore.so @lib/libxwalkcore.so.rsp && {
readelf -d lib/libxwalkcore.so | grep SONAME ; nm -gD -f p lib/libxwalkcore.so
| cut -f1-2 -d' '; } > lib/libxwalkcore.so.TOC; else
/home/dachen/crosswalk-src/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
-shared -Wl,-z,now -Wl,-z,relro -Wl,--fatal-warnings -Wl,-z,defs
-Wl,-z,noexecstack -fPIC
-B/home/dachen/crosswalk-src/src/third_party/binutils/Linux_x64/Release/bin
-Wl,--no-fatal-warnings
-L/home/dachen/crosswalk-src/src/third_party/etf/etf_dynamics/android/libs/armeabi
-fuse-ld=gold -Wl,--no-undefined
--sysroot=../../third_party/android_tools/ndk//platforms/android-14/arch-arm
-nostdlib
-L../../third_party/android_tools/ndk//sources/cxx-stl/stlport/libs/armeabi-v7a
-Wl,--exclude-libs=libgcc.a -Wl,--exclude-libs=libstlport_static.a
-Wl,--exclude-libs=libcommon_audio.a -Wl,--exclude-libs=libcommon_audio_neon.a
-Wl,--exclude-libs=libcommon_audio_sse2.a -Wl,--exclude-libs=libiSACFix.a
-Wl,--exclude-libs=libisac_neon.a -Wl,--exclude-libs=libopus.a
-Wl,--exclude-libs=libvpx.a -Wl,--icf=safe -Wl,-shared,-Bsymbolic
../../third_party/android_tools/ndk//platforms/android-14/arch-arm/usr/lib/crtbegin_so.o
-Wl,--version-script=/home/dachen/crosswalk-src/src/build/android/android_no_jni_exports.lst
-Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--warn-shared-textrel -o
lib/libxwalkcore.so -Wl,-soname=libxwalkcore.so @lib/libxwalkcore.so.rsp && {
readelf -d lib/libxwalkcore.so | grep SONAME ; nm -gD -f p lib/libxwalkcore.so
| cut -f1-2 -d' '; } > lib/libxwalkcore.so.tmp && if ! cmp -s
lib/libxwalkcore.so.tmp lib/libxwalkcore.so.TOC; then mv
lib/libxwalkcore.so.tmp lib/libxwalkcore.so.TOC ; fi;
fi../../components/visitedlink/browser/visitedlink_master.cc:68: error:
undefined reference to 'base::OpenFile(base::FilePath const&, char
const*)'../../components/visitedlink/browser/visitedlink_master.cc:542: error:
undefined reference to 'base::OpenFile(base::FilePath const&, char const*)'
../../xwalk/runtime/browser/runtime_download........
This error happens when build shared library libxwalkcore.so,which depends on
web_contents_delegate_android then depends on base.gyp:base,it's strange that
the build command does not link libbase.a and the native library libgdndk.so.
Could anybody give me some ideas about that?
Thanks,Gary
Hi Raphael,
Thanks for your response:From your message it is not clear how you specified
this new library in
your build system. From what I could gather you should not need it in
the host part at all (and you also cannot use it since they're for
different architectures anyway). As far as I can see it should only be
used by the target targets.
For your comments,I added some details addition:
I replaced some files with myown in base.gypi for file I/O like: 522
#'rand_util_posix.cc',
523 'third_party/etf_dynamics/etf_rand_util_posix.cc',the source
file refer the methods which are exported from a shared library (ARM, EABI5
version 1).source "rand_util_posix.cc" is defined here in base.gypi:'includes':
[ 'trace_event/trace_event.gypi', ], 'target_defaults': { 'variables':
{ 'base_target': 0, 'base_i18n_target': 0, },
'target_conditions': [ # This part is shared between the targets defined
below. ['base_target==1', { 'sources': [
I link the arm lib in target 'base_jni_headers',which is defined in base.gyp:
['OS == "android"', {1340 'targets': [1341 {1342 # GN:
//base:base_jni_headers1343 'target_name': 'base_jni_headers',1344
'type': 'none',1345 'sources': [1346
'android/java/src/org/chromium/base/ApplicationStatus.java',1347
'android/java/src/org/chromium/base/AnimationFrameTimeHistogram.java',1348
'android/java/src/org/chromium/base/BuildInfo.java',1349
'android/java/src/org/chromium/base/CommandLine.java',1350
'android/java/src/org/chromium/base/ContentUriUtils.java',1351
'android/java/src/org/chromium/base/CpuFeatures.java',1352
'android/java/src/org/chromium/base/EventLog.java',1353
'android/java/src/org/chromium/base/FieldTrialList.java',1354
'android/java/src/org/chromium/base/ImportantFileWriterAndroid.java',1355
'android/java/src/org/chromium/base/JNIUtils.java',1356
'android/java/src/org/chromium/base/JavaHandlerThread.java',1357
'android/java/src/org/chromium/base/LocaleUtils.java',1358
'android/java/src/org/chromium/base/MemoryPressureListener.java',1359
'android/java/src/org/chromium/base/PathService.java',1360
'android/java/src/org/chromium/base/PathUtils.java',1361
'android/java/src/org/chromium/base/PowerMonitor.java',1362
'android/java/src/org/chromium/base/SysUtils.java',1363
'android/java/src/org/chromium/base/SystemMessageHandler.java',1364
'android/java/src/org/chromium/base/ThreadUtils.java',1365
'android/java/src/org/chromium/base/TraceEvent.java',1366
'android/java/src/org/chromium/base/library_loader/LibraryLoader.java',1367
'android/java/src/org/chromium/base/metrics/RecordHistogram.java',1368
'android/java/src/org/chromium/base/metrics/RecordUserAction.java',1369
],1370 'variables': {1371 'jni_gen_package':
'base',1372 },1373 'dependencies': [1374
'android_runtime_jni_headers',1375 ],1376 'link_settings':
{1377 'ldflags': [1378 '-L<!(cd <(DEPTH) && pwd
-P)/third_party/etf/etf_dynamics/android/libs/armeabi',1379
],1380 'libraries': [1381 '-lgdndk',1382
],1383 'cxxflags':[1384 '-m32'1385
],1386 },1387 'includes': [
'../build/jni_generator.gypi' ],
1388 },
If I just need a arm arch build,the simplest way to change that I think
is:don't build the 'host' targeted in build commands or change some codes in
some gypi file with specified arguments,is that correct?Currently,I use the
ninja -C out/Release xwalk_core_library -j8,which default builds both 'host'
and 'target'(defined the value of _toolset)
Another way is:keep the 'host' part the original,and move my change to a
separate target_condition,I think it's too difficult for me.
Thanks,Gary
-------- 原始邮件 --------
发件人:[email protected]
时 间:2015年8月29日 03:00(星期六)
收件人:[email protected]
主题:Crosswalk-dev Digest, Vol 24, Issue 47
Send Crosswalk-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Crosswalk-dev digest..."
Today's Topics:
1. Re: link error for build cross walk by integrating a library
(ARM, EABI5 version 1) (Raphael Kubo da Costa)
2. Re: Intent to switch: using our own GitHub copy of the OpenCL
headers (Raphael Kubo da Costa)
3. Re: Intent to switch: using our own GitHub copy of the OpenCL
headers (Hu, Jiajie)
4. Re: Intent to switch: using our own GitHub copy of the OpenCL
headers (Raphael Kubo da Costa)
5. Re: Intent to switch: using our own GitHub copy of the
OpenCL
headers (Hu, Jiajie)
----------------------------------------------------------------------
Message: 1
Date: Fri, 28 Aug 2015 11:03:18 +0200
From: Raphael Kubo da Costa <[email protected]>
To: Crosswalk-dev <[email protected]>
Subject: Re: [Crosswalk-dev] link error for build cross walk by
integrating a library (ARM, EABI5 version 1)
Message-ID: <[email protected]>
Content-Type: text/plain
Gary Chine <[email protected]> writes:
> The library libgdndk.so is referenced by obj.host/base/libbase.a ,I
> add '-m32' as ldflags.
[...]
> I wonder why I need to build on the 'host' toolset,but not only the
> 'target' toolset.
>From your message it is not clear how you specified this new library in
your build system. From what I could gather you should not need it in
the host part at all (and you also cannot use it since they're for
different architectures anyway). As far as I can see it should only be
used by the target targets.
------------------------------
Message: 2
Date: Fri, 28 Aug 2015 11:05:23 +0200
From: Raphael Kubo da Costa <[email protected]>
To: "crosswalk-dev\@lists.crosswalk-project.org"
<[email protected]>
Subject: Re: [Crosswalk-dev] Intent to switch: using our own GitHub
copy of the OpenCL headers
Message-ID: <[email protected]>
Content-Type: text/plain
"Hu, Jiajie" <[email protected]> writes:
> Thanks for proposal and actually I have had the same idea for a long
> time that SVN should no longer be used for the OpenCL headers.
>
> However, I prefer to add these headers to third_party/khronos in
> chromium-crosswalk.git like
> https://github.com/crosswalk-project/chromium-crosswalk/pull/188, just
> as how OpenGL headers are managed in Chromium, instead of hosting them
> in a dedicated repo.
>
> WDYT?
Is there a reason why you think this is a better approach? I'd like to
avoid adding new commits (especially ones like this which have no chance
of being upstreamed as-is) to chromium-crosswalk if at all possible, so
putting things in a separate repository was the best I could come up
with.
------------------------------
Message: 3
Date: Fri, 28 Aug 2015 10:47:11 +0000
From: "Hu, Jiajie" <[email protected]>
To: "[email protected]"
<[email protected]>
Subject: Re: [Crosswalk-dev] Intent to switch: using our own GitHub
copy of the OpenCL headers
Message-ID:
<e042790f5644a34faa76b670e591476601e47...@shsmsx102.ccr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
OK.. I'm just expressing my own opinion, and I just want to keep things
consistent with WebGL / OpenGL. It's not quite a big issue for me where the
headers are hosted.
You mentioned that you want to avoid adding new commits (especially ones which
have no chance of being upstreamed) to chromium-crosswalk, this raises another
concern for me. For historical reasons, by now almost all WebCL code are
located in src/WebKit/Source/modules/webcl, and this minimizes the effort
required during rebase. However, strictly speaking this is not the right
architecture because system hardware is accessed within Blink. We are
considering moving some code from Blink to src/content and migrating to
Chromium's multi-process model gradually so that WebCL can be used on platforms
other than Android. This will apparently be a much more complex task than
committing the OpenCL headers (see how WebGL is implemented), so I'm afraid
that will be totally contrary to the philosophy of avoiding new commits.
BR
Jiajie
-----Original Message-----
From: Crosswalk-dev [mailto:[email protected]]
On Behalf Of Raphael Kubo da Costa
Sent: Friday, August 28, 2015 5:05 PM
To: [email protected]
Subject: Re: [Crosswalk-dev] Intent to switch: using our own GitHub copy of the
OpenCL headers
"Hu, Jiajie" <[email protected]> writes:
> Thanks for proposal and actually I have had the same idea for a long
> time that SVN should no longer be used for the OpenCL headers.
>
> However, I prefer to add these headers to third_party/khronos in
> chromium-crosswalk.git like
> https://github.com/crosswalk-project/chromium-crosswalk/pull/188, just
> as how OpenGL headers are managed in Chromium, instead of hosting them
> in a dedicated repo.
>
> WDYT?
Is there a reason why you think this is a better approach? I'd like to avoid
adding new commits (especially ones like this which have no chance of being
upstreamed as-is) to chromium-crosswalk if at all possible, so putting things
in a separate repository was the best I could come up with.
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
------------------------------
Message: 4
Date: Fri, 28 Aug 2015 15:26:51 +0200
From: Raphael Kubo da Costa <[email protected]>
To: "crosswalk-dev\@lists.crosswalk-project.org"
<[email protected]>
Subject: Re: [Crosswalk-dev] Intent to switch: using our own GitHub
copy of the OpenCL headers
Message-ID: <[email protected]>
Content-Type: text/plain
"Hu, Jiajie" <[email protected]> writes:
> OK.. I'm just expressing my own opinion, and I just want to keep
> things consistent with WebGL / OpenGL. It's not quite a big issue for
> me where the headers are hosted.
Alright, in this case I'll move forward with hosting them in a separate
repository.
> You mentioned that you want to avoid adding new commits (especially
> ones which have no chance of being upstreamed) to chromium-crosswalk,
> this raises another concern for me. For historical reasons, by now
> almost all WebCL code are located in src/WebKit/Source/modules/webcl,
> and this minimizes the effort required during rebase. However,
> strictly speaking this is not the right architecture because system
> hardware is accessed within Blink. We are considering moving some code
> from Blink to src/content and migrating to Chromium's multi-process
> model gradually so that WebCL can be used on platforms other than
> Android. This will apparently be a much more complex task than
> committing the OpenCL headers (see how WebGL is implemented), so I'm
> afraid that will be totally contrary to the philosophy of avoiding new
> commits.
Yeah, this is one big topic to discuss then. I don't have much to say at
the moment; basically if we decide it's the way forward and it pays off
there isn't a lot we can do other than try to minimise the changes we
make to existing files (just like we do in Blink).
------------------------------
Message: 5
Date: Fri, 28 Aug 2015 17:35:18 +0000
From: "Hu, Jiajie" <[email protected]>
To: "[email protected]"
<[email protected]>
Subject: Re: [Crosswalk-dev] Intent to switch: using our own GitHub
copy of the OpenCL headers
Message-ID:
<e042790f5644a34faa76b670e591476601e47...@shsmsx102.ccr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
I just realized that we may depend on Khronos Vulkan and SPIR-V headers if we
are going to implement some sort of fallback when OpenCL driver is not
installed. The background is that OpenCL is not part of AOSP, but Google has
confirmed that Vulkan will be available on Android in the future. In that case,
we can compile OpenCL kernel to SPIR-V and pass it to Vulkan to achieve the
fallback. Please take it into consideration that we will potentially host these
headers as well.
BR
Jiajie
-----Original Message-----
From: Crosswalk-dev [mailto:[email protected]]
On Behalf Of Raphael Kubo da Costa
Sent: Friday, August 28, 2015 9:27 PM
To: [email protected]
Subject: Re: [Crosswalk-dev] Intent to switch: using our own GitHub copy of the
OpenCL headers
"Hu, Jiajie" <[email protected]> writes:
> OK.. I'm just expressing my own opinion, and I just want to keep
> things consistent with WebGL / OpenGL. It's not quite a big issue for
> me where the headers are hosted.
Alright, in this case I'll move forward with hosting them in a separate
repository.
> You mentioned that you want to avoid adding new commits (especially
> ones which have no chance of being upstreamed) to chromium-crosswalk,
> this raises another concern for me. For historical reasons, by now
> almost all WebCL code are located in src/WebKit/Source/modules/webcl,
> and this minimizes the effort required during rebase. However,
> strictly speaking this is not the right architecture because system
> hardware is accessed within Blink. We are considering moving some code
> from Blink to src/content and migrating to Chromium's multi-process
> model gradually so that WebCL can be used on platforms other than
> Android. This will apparently be a much more complex task than
> committing the OpenCL headers (see how WebGL is implemented), so I'm
> afraid that will be totally contrary to the philosophy of avoiding new
> commits.
Yeah, this is one big topic to discuss then. I don't have much to say at the
moment; basically if we decide it's the way forward and it pays off there isn't
a lot we can do other than try to minimise the changes we make to existing
files (just like we do in Blink).
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
------------------------------
Subject: Digest Footer
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
------------------------------
End of Crosswalk-dev Digest, Vol 24, Issue 47
*********************************************
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
