On 2017-03-02 13:01+0100 Bernhard Seckinger wrote:
Basically it's (works)
/usr/bin/gdc -I.. -fversion=slang -oCMakeFiles/starbattle.dir/__/puzzle
-c /home/berni/Croco/Entwicklung/Croco/types/puzzle.d
[...]
/usr/bin/gdc CMakeFiles/starbattle.dir/starbattle
CMakeFiles/starbattle.dir/starbattle_check_puzzle
CMakeFiles/starbattle.dir/starbattle_check_solution
CMakeFiles/starbattle.dir/__/puzzle
CMakeFiles/starbattle.dir/__/puzzle_options
CMakeFiles/starbattle.dir/__/puzzle_unittest
CMakeFiles/starbattle.dir/__/spf_tools CMakeFiles/starbattle.dir/__/puzzle_io
CMakeFiles/starbattle.dir/__/puzzle_timer CMakeFiles/starbattle.dir/__/slang
-ostarbattle -L/usr/lib/gcc/x86_64-linux-gnu/6 ../libslang_wrapper.o.a
-lslang -lc
vs. (does not work)
/usr/bin/gdc -O3 -fomit-frame-pointer -fweb -frelease -finline-functions
-I.. -fversion=slang -oCMakeFiles/starbattle.dir/__/puzzle
-c /home/berni/Croco/Entwicklung/Croco/types/puzzle.d
[...]
/usr/bin/gdc -O3 -fomit-frame-pointer -fweb -frelease -finline-functions
CMakeFiles/starbattle.dir/starbattle
CMakeFiles/starbattle.dir/starbattle_check_puzzle
CMakeFiles/starbattle.dir/starbattle_check_solution
CMakeFiles/starbattle.dir/__/puzzle
CMakeFiles/starbattle.dir/__/puzzle_options
CMakeFiles/starbattle.dir/__/puzzle_unittest
CMakeFiles/starbattle.dir/__/spf_tools CMakeFiles/starbattle.dir/__/puzzle_io
CMakeFiles/starbattle.dir/__/puzzle_timer CMakeFiles/starbattle.dir/__/slang
-ostarbattle -L/usr/lib/gcc/x86_64-linux-gnu/6 ../libslang_wrapper.o.a
-lslang -lc
One can even remove "-fomit-frame-pointer -fweb -frelease -finline-functions"
and set -O1 instead of -O3 to get the same result.
Hi Bernhard:
The problem is that CMake has no native support for gdc so several
external projects have supplied that support. For example, PLplot
(the project I am associated with) obtained our CMake support for gdc
from CMakeD (by Selman Ulug and Tim Burrell) a decade ago, and we have
been tweaking it ever since for just our own needs, but we have no
interest in supporting CMakeD for others because the strong impression
I have is that project has been superseded by other projects which we
intend to move to eventually once we have evaluated them.
It appears you are using https://github.com/dcarp/cmake-d for CMake
gdc support which as far as I can tell (e.g., from the license which
does not mention Ulug or Burrel) is completely different from CMakeD.
Anyhow, you should contact the authors of cmake-d with your bug report
and/or try other modern possibilities revealed by, say, a google
search for the terms <cmake gdc>.
My advice for putting together that bug report is to create the
simplest standalone example of the problem that is possible (e.g.,
consiting of a CMakeLists.txt file that builds and installs a "hello,
world" D application + D language source code for that application.
Then after configuring that simple test project with
-DCMAKE_BUILD_TYPE=Release, run "make VERBOSE=1" which tells you
exactly the commands that were executed which lead to the linking
error. Afterward replicate that last (gdc)
command that generated the linker error by hand, and then start
changing (by hand) the gdc options until you isolate the one that is
causing the linker issue.
Assuming you isolate the issue that way, then you have demonstrated a
bug in your particular CMake support for gdc for the
-DCMAKE_BUILD_TYPE=Release case which you should report to the authors
of your CMake gdc support. That simple self-contained example will be
a big help to them in replicating the issue and figuring it out. And
if they are not responsive to your bug report, perhaps it is time to
move to some other CMake gdc support project which is more responsive
or which does not have the issue with -DCMAKE_BUILD_TYPE=Release that
you have found with the cmake-d project.
Good luck, and I would appreciate you sharing with me (and possibly
this list) how it goes since I am interested in trying something
different from a tweaked CMakeD for gdc language support in
the CMake-based PLplot build system.
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
