[cmake-developers] CMAKE 3.7 (for Android target) error: crtbegin_dynamic.o:crtbrand.c:function _start: error: undefined reference to 'main’
Hi,
Not sure if this is the place to ask my question but here we go:
I am trying to build C++ code targeting the Android platform. I already have
the whole system setup to generate VisualStudio projects and it is using the
Nsight Tegra plug-in.
I’ve been asked to update the CMake files so we can still target Android but
not using VisualStudio in hope to migrate to AndroidStudio.
So far, I managed to create a new toolchain file containing the following:
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang)
set(CMAKE_ANDROID_API 21)
set(CMAKE_ANDROID_NDK $ENV{ANDROID_HOME})
set(CMAKE_ANDROID_SKIP_ANT_STEP 0)
set(CMAKE_ANDROID_JAVA_SOURCE_DIR java)
set(CMAKE_ANDROID_BUILD_SYSTEM GradleBuild)
With these settings, I can successfully compile the whole project source files
but when I get to the link pass, it fails with the error:
C:/NVPACK/android-ndk-r10e/platforms/android-21/arch-arm/usr/lib/../lib\crtbegin_dynamic.o:crtbrand.c:function
_start: error: undefined reference to 'main’
I believe that I am missing the equivalent steps that are taken care by the
“Gradle Build” steps found in the VisualStudio project.
My understanding is that these Gradle steps are responsible for embedding the
AndroidManifest (that, I’ve been told, will define the ‘main’) and generate the
apk file from the so.
Is this indeed what I am missing? Also, can anyone confirm if CMake 3.7 does
provide the equivalent steps or if I need to define them myself?
Thank you in advance
Regalir
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Android variables
On 11/11/2016 01:51 PM, Brad King wrote: > Okay, thanks. I'll investigate how to properly expose this information. Please see: https://gitlab.kitware.com/cmake/cmake/merge_requests/254 -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET
On 07/18/2016 09:14 AM, Brad King wrote: > FindBISON: Change usage of [VERBOSE ] to [VERBOSE []] > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad2497aa BTW, this caused a regression reported here: * https://gitlab.kitware.com/cmake/cmake/issues/16426 Please take a look at the fix here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/250 Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
Am 14.11.2016 um 12:41 schrieb Alan W. Irwin:
> On 2016-11-14 09:06+0100 Sebastian Holtermann wrote:
>
>> What probably could be done is to add
>> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
>> to the INCLUDE_DIRECTORIES of the target and then generate all
>> #included moc file there, accepting the risk of intra target name
>> collisions.
>
> Hi Sebastian:
>
> Your compromise idea above sounds good to me!
>
Btw. I liked your
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
${HEADERPATHCHECKSUM}/
moc_${HEADERNAME}.cpp
approach.
It could be used for the moc_.cpp files that are not
manually #included and therefore can have any name.
Over the current
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
moc_${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
scheme it has the advantages that
1) moc_.cpp files are grouped by their source directory
2) ${HEADERNAME} is kept intact and does not get shortened
3) fewer weird looking checksum names ;)
1) and 2) are generally helpful to find and debug moced files I think.
There are a some other changes to the automoc system I would like to
propose / work on. I'm currently busy with an other project though.
-Sebastian
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
On 2016-11-14 09:06+0100 Sebastian Holtermann wrote:
What probably could be done is to add
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to the INCLUDE_DIRECTORIES of the target and then generate all
#included moc file there, accepting the risk of intra target name
collisions.
Hi Sebastian:
Your compromise idea above sounds good to me!
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
Am 13.11.2016 um 07:48 schrieb Alan W. Irwin:
> On 2016-10-22 19:49+0200 Sebastian Holtermann wrote:
>
> [...]
>> Actually I made an implementation in 3.6.0 that generated the moc files
>> in the a build tree subdirectory correspoding to the header path.
>> But that blew up on some projects because the generated paths got too
>> long for some compiĺers. That implementation was theefore reverted.
>> In 3.7 there is a new approatch that generates the moc files in
>> ${CMAKE_BINARY_DIR}/
>>${TARGETNAME}_automoc.dir/
>>${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
>> This ensures that the paths don't get too long and that there won't be
>> any name collisions.
>
> Hi Sebastian:
>
> After a substantial break to finish off a different project, I have
> now had a chance to return to the present topic using my attached
> test_automoc project. (Also available in the cmake/test_automoc
> subdirectory of the PLplot git master branch that can be accessed at
> ) states the
> following:
>
> "However, if multiple source files in different directories do this
> [i.e., contain an "#include "moc_.cpp" when the header
> name is .h] then their generated moc files would
> collide. In this case a diagnostic will be issued."
>
> For the life of me, I cannot find a way to generate that diagnostic.
> Instead, three different targets (two targets concerning the same
> implementation code and header in the same directory and a third
> target for a copy of that same implementation code and header in a
> different directory) generate at build time a file named
> moc_test_q_object.cpp in the same build directory at different times.
> This is a clear example of a three-way name collision, but CMake does
> not issue a diagnostic for any of these targets concerning that
> collision contrary to the above documentation.
>
> Could you please take a look at the three last executables configured
> for this test case (helloworld_automoc_same_include,
> helloworld_automoc_same_include1, and
> helloworld_automoc_same_include2) to see why that collision diagnostic
> is not being issued with cmake-3.7.0? Better yet, of course, would be
> to solve these remaining name collisions completely by using a
> modification of your idea above, i.e., for this special case where
> users implementation code contained
>
> #include "moc_.cpp"
>
> then moc should generate the file
>
> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp
>
>
> Note, the generated moc file has the name expected by the #include so
> I believe this idea would work so long as automoc automatically
> appended
> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to
> the target INCLUDE_DIRECTORIES property.
>
Hi Alan,
the automoc diagnostic checks for name collisions within a single target
only, not across multiple targets - as in your example.
The problem I see is that all moc files included by the
#include "moc_.cpp"
scheme get generated in ${CMAKE_BINARY_DIR}.
It would be better to generate them in
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to avoid inter target name collisions.
Your solution using the path checksum as well would be event better
as it avoids name collisions even within a target.
The problem there is though that it would require to add
a .cpp file specific -I compiler statement for every .cpp file
that includes a moc file.
This is hard to do with the current automoc implementation.
I would not want to do it.
What probably could be done is to add
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to the INCLUDE_DIRECTORIES of the target and then generate all
#included moc file there, accepting the risk of intra target name
collisions.
-Sebastian
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other
