GoogleCodeExporter
commented
9 years ago [deleted comment]Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago [deleted comment]Which version of dmd are you using? I can reproduce your problem with version
2.039. But with version 2.049 it works. Can you try version 2.049?
Original comment by jens.k.mueller@gmail.com on 20 Sep 2010 at 2:40
GoogleCodeExporter
commented
9 years ago I was using 2.048. Now I moved to 2.049 and the cmaked2 tests work fine.
My own project also compiles fine, however it fails to link with the message:
Linking D executable taula
Error: unrecognized switch '-lpthread'
I have no reference to pthreads in my makefiles or code, and i have seen that
cmaked2 only has one but it is commented out. Then i have seen that the dmd
source code contains this:
./dmd2.0.49/src/dmd/link.c: argv.push((void *)"-lpthread");
Which makes me think that the option is being added my dmd itself. I have seen
though, that the test app7 uses threads and it seems to work fine.
I will try to investigate a little bit more.
Original comment by camin...@gmail.com on 20 Sep 2010 at 3:57
GoogleCodeExporter
commented
9 years ago Enabling the cmake verbose mode i get the failing command:
Linking D executable taula
cd /home/jordi/d2/crosa/build/debug/taula && /usr/bin/cmake -E
cmake_link_script CMakeFiles/taula.dir/link.txt --verbose=1
/home/jordi/d2/dmd2/linux/bin/dmd -g -debug -L--export-dynamic
CMakeFiles/taula.dir/application.o -oftaula ../crosa/libcrosa.a
../extern/derelict/libderelict.a -L-ldl /usr/lib/libfreetype.so
/usr/lib/libSDLmain.a /usr/lib/libSDL.so -lpthread /usr/lib/libGLU.so
/usr/lib/libGL.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libX11.so
/usr/lib/libXext.so
Error: unrecognized switch '-lpthread'
It seems all the last part of the command might come from the cmake commands to
locate the SDL, FreeType, GL and DevIL libraries. I have modified the app7
CMakeLists.txt of the tests like this:
# A more complex library test.
include( FindOpenGL )
ADD_EXECUTABLE( app_7 app_7.d )
ADD_TEST( app_7 app_7 )
target_link_libraries( app_7
${OPENGL_LIBRARIES}
)
And it generates a simialr problem (not with pthreads, but with extra linking
parameters).
I am currently used a hacked and slashed version of the cmaked in dsource that
i patched long time ago. It works for my case even with this external
libraries. Unfortunately i modified it in a careless way and it is not useful
for other projects. I ay try to look at how this is handled in that version.Original comment by camin...@gmail.com on 20 Sep 2010 at 4:22
GoogleCodeExporter
commented
9 years ago More info: my patched version actually uses gcc for linking. Generating this
command:
Linking D executable taula
cd /home/jordi/d2/crosa/build/debug/taula && /usr/bin/cmake -E
cmake_link_script CMakeFiles/taula.dir/link.txt --verbose=1
gcc CMakeFiles/taula.dir/application.d.o -o taula ../crosa/libcrosa.a
../extern/derelict/libderelict.a -ldl /usr/lib/libfreetype.so
/usr/lib/libSDLmain.a /usr/lib/libSDL.so -lpthread /usr/lib/libGLU.so
/usr/lib/libGL.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libX11.so
/usr/lib/libXext.so -lpthread -lm -L/home/jordi/d2/dmd2/linux/lib -lphobos2
-ldruntime
Original comment by camin...@gmail.com on 20 Sep 2010 at 4:26
GoogleCodeExporter
commented
9 years ago I think the problem is that dmd uses a weird syntax for command line parameters
passed through to the linker. The syntax should be -L-lpthread. Somehow the
wrong syntax -lpthread is sneaking in there.
Eventually I would like to leave the existing regression tests alone, but add a
new test to try and catch this pthread issue.Original comment by kingshiz...@gmail.com on 21 Sep 2010 at 3:18
GoogleCodeExporter
commented
9 years ago Even though this issue now moved into another direction, I tried using
dmd.2.048 to reproduce the original issue ("Error: Error reading file
'CMakeFiles/lib_1.dir/lib_1.o'") but I couldn't reproduce. I tried also
dmd.2.047 which works as well. But with dmd.2.039 I can reproduce it. Are you
sure about your dmd version?Original comment by jens.k.mueller@gmail.com on 21 Sep 2010 at 8:06
GoogleCodeExporter
commented
9 years ago A possible test could be:
find_package(Threads)
# A more complex library test.
ADD_EXECUTABLE( app_7 app_7.d )
target_link_libraries(app_7
-L${CMAKE_THREAD_LIBS_INIT}
)
ADD_TEST( app_7 app_7 )
And a quick workaround is changing "-L${CMAKE_THREAD_LIBS_INIT}" to
"-L${CMAKE_THREAD_LIBS_INIT}".
Anyway we should try to make cmake add the "-L" for us.
The next problem is that shared libraries are not supported by dmd yet. In the
meantime one could try to use gcc as linker as you did. How did you do this?Original comment by jens.k.mueller@gmail.com on 21 Sep 2010 at 8:34
GoogleCodeExporter
commented
9 years ago I have it nastily hardcoded in the CMakeDInformation.cmake file like this:
IF(NOT CMAKE_D_LINK_EXECUTABLE)
IF(CMAKE_COMPILER_IS_GDC)
SET(CMAKE_D_LINK_EXECUTABLE
"<CMAKE_D_COMPILER> <FLAGS> <CMAKE_D_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> ${CMAKE_OUTPUT_D_FLAG}<TARGET> <LINK_LIBRARIES> ${DSTDLIB_FLAGS} ${DSTDLIB_TYPE}")
ELSE(CMAKE_COMPILER_IS_GDC)
IF(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
SET(CMAKE_D_LINK_EXECUTABLE
"gcc ${DLINK_FLAGS} <CMAKE_D_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES> -lpthread -lm ${DSTDLIB_FLAGS}")
ELSE(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
SET(CMAKE_D_LINK_EXECUTABLE
"<CMAKE_D_COMPILER> <FLAGS> <CMAKE_D_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> ${CMAKE_OUTPUT_D_FLAG}<TARGET> <LINK_LIBRARIES>")
ENDIF(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
ENDIF(CMAKE_COMPILER_IS_GDC)
ENDIF(NOT CMAKE_D_LINK_EXECUTABLE)
but this is not an option for the general case.
Your solution of prepending -L in the comment 8, wouldn't work in the case of
more than one parameter in the CMAKE_THREAD_LIBS_INIT variable, though.Original comment by camin...@gmail.com on 22 Sep 2010 at 12:27
GoogleCodeExporter
commented
9 years ago I've been searching a bit for the -lpthread problem. The problem is that the
'-lpthread' is more or less hard coded in cmake's FindThreads.cmake. I don't
know why they do it like this.
The OpenGL example fails because it tries linking a shared object but dmd does
not support linking shared libraries. Unfortunately I don't know how to tell
cmake to use the a static library version of OpenGL. With FindBoost you can set
Boost_USE_STATIC_LIBS. Original comment by jens.k.mueller@gmail.com on 27 Sep 2010 at 9:53
GoogleCodeExporter
commented
9 years ago Hi again,
It seems to be the normal way for all CMake commands of the type FindXXXX to return a set of parameters for the C/C++ compiler and linker that shouldn't be "manipulated" and just passed directly. In the case of OpenGL for example, it doesn't usually make sense to use static libraries, as the GL library itself is part of the graphic driver which change from computer to computer.
I presume this is the reason why the previous developers of cmaked were using gcc for linking in Linux.
What are the benefits of using dmd? In linux at least, dmd will still use gcc's linker internally, i think. But this might be a question for the dmd developers...
j.Original comment by camin...@gmail.com on 28 Sep 2010 at 1:45
GoogleCodeExporter
commented
9 years ago Good question about linking with dmd vs. gcc. If there is a clear winner, it's
easy to change the weighted preference.Original comment by kingshiz...@gmail.com on 28 Sep 2010 at 4:08
GoogleCodeExporter
commented
9 years ago I just came around a way to make the workaround less nasty. Maybe even good.
add_executable(foo src/bar.d)
target_link_libraries(foo /path/to/lib/libphobos2.a)
set_target_properties(foo PROPERTIES LINKER_LANGUAGE C)
The key observation is that you can define which language to use for linking.
What do you think?
But one should provide a way of finding the phobos2 library. So it becomes:
find_package(Phobos2)
target_link_libraries(foo ${PHOBOS2_LIBRARIES})Original comment by jens.k.mueller@gmail.com on 3 Nov 2010 at 8:34
GoogleCodeExporter
commented
9 years ago I added a FindPhobos.cmake to the repository.
find_package(Phobos)
target_link_libraries(foo ${PHOBOS_LIBRARY})
should work.
Beware that I check for the import/include path _and_ the library path.
You have to set proper paths for this. E.g.
cmake -DCMAKE_PREFIX_PATH="/path/to/lib;/path/to/src/phobos/"Original comment by jens.k.mueller@gmail.com on 3 Nov 2010 at 9:20
Original issue reported on code.google.com by
camin...@gmail.comon 13 Sep 2010 at 2:18