Re: [CMake] MinGW Link with -l instead of path?

2013-04-04 Thread Hendrik Sattler 

Am 2013-04-03 17:25, schrieb J Decker:

All of these articles say the way to avoid having an absolute path
stored in the linked output is to use -L dir -l lib ... which is
definatly not what cmake is producing.  Reflecting on this, maybe I
can replace target_link_libraries with manually specified link_flags;
maybe some sort of similarly named macro


Did you try after a call to make install? E.g. a local try with make 
install DESTDIR=localtest


HS

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW Link with -l instead of path?

2013-04-04 Thread J Decker 
On Wed, Apr 3, 2013 at 9:12 AM, J Decker d3c...@gmail.com wrote:

 alternate target_link_libraries.  Usage is the same.  Test if each library
 to link is a target, get that targets path, and break it into parts and add
 it to LINK_FLAGS else add with target_link_libraries...

 macro(my_target_link_libraries target )
 if(CMAKE_COMPILER_IS_GNUCC)
foreach( target_lib ${ARGN} )
   if( TARGET ${target_lib} )
  get_property( lib_path TARGET ${target_lib} PROPERTY LOCATION)
  if( ${lib_path} MATCHES (.*)/([^/]*)$ )
 get_target_property(existing_link_flags ${target}
 LINK_FLAGS)


#  Revision to handle OUTPUT_NAME overridden targets.
 get_property( existing_outname TARGET ${target_lib} PROPERTY
OUTPUT_NAME )
 if( NOT existing_outname )
 set( existing_outname ${target_lib} )
 endif( NOT existing_outname )



 if(existing_link_flags)
 +set(new_link_flags ${existing_link_flags} -L
 ${CMAKE_MATCH_1} -l ${existing_outname })
 else()
 +set(new_link_flags -L ${CMAKE_MATCH_1} -l
 ${existing_outname})
 endif()
 set_target_properties( ${target} PROPERTIES LINK_FLAGS
 ${new_link_flags})
  endif( ${lib_path} MATCHES (.*)/([^/]*)$ )
   else()
  target_link_libraries( ${target} ${target_lib} )
   endif( TARGET ${target_lib} )
endforeach( target_lib ${ARGN} )
 else()
 target_link_libraries( ${target} ${ARGN} )
 endif()
 endmacro()




macro(my_target_link_libraries target )
if(CMAKE_COMPILER_IS_GNUCC)
   foreach( target_lib ${ARGN} )
  if( TARGET ${target_lib} )
 get_property( lib_path TARGET ${target_lib} PROPERTY LOCATION)
 get_property( existing_outname TARGET ${target_lib} PROPERTY
OUTPUT_NAME )
 if( NOT existing_outname )
 set( existing_outname ${target_lib} )
 endif( NOT existing_outname )
 if( ${lib_path} MATCHES (.*)/([^/]*)$ )
get_target_property(existing_link_flags ${target}
LINK_FLAGS)
if(existing_link_flags)

set(new_link_flags ${existing_link_flags} -L
${CMAKE_MATCH_1} -l ${existing_outname})
else()
set(new_link_flags -L ${CMAKE_MATCH_1} -l
${existing_outname})
endif()
set_target_properties( ${target} PROPERTIES LINK_FLAGS
${new_link_flags})
 endif( ${lib_path} MATCHES (.*)/([^/]*)$ )
  else()
 target_link_libraries( ${target} ${target_lib} )
  endif( TARGET ${target_lib} )
   endforeach( target_lib ${ARGN} )
else()
target_link_libraries( ${target} ${ARGN} )
endif()
endmacro()
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW Link with -l instead of path?

2013-04-03 Thread J Decker 
All of these articles say the way to avoid having an absolute path stored
in the linked output is to use -L dir -l lib ... which is definatly not
what cmake is producing.  Reflecting on this, maybe I can replace
target_link_libraries with manually specified link_flags; maybe some sort
of similarly named macro

http://stackoverflow.com/questions/14551204/any-way-to-make-ld-record-shared-library-name-only-no-subdirs

http://stackoverflow.com/questions/1124809/embedding-absolute-path-for-shared-libraries

http://stackoverflow.com/questions/2726993/g-how-to-specify-preference-of-library-path




On Tue, Apr 2, 2013 at 9:29 AM, J Decker d3c...@gmail.com wrote:

 So from the silence, either I described my issue badly, or there isn't a
 way?

 From the script at the end, when generating 'unix makefiles' with a mingw
 environment, or MingW makefiles, these are the gcc commands

 (compile .obj)
 c:/tools/unix/mingw.mangled/bin/gcc.exe  -Dtest2_EXPORTS  -o
 CMakeFiles/test2.dir/test2.c.obj   -c M:/tmp/cmake_crash/test4/test2.c
 (link .dll)
 c:/tools/unix/mingw.mangled/bin/gcc.exe -shared -o libtest2.dll
 -Wl,--out-implib,libtest2.dll.a
 -Wl,--major-image-version,0,--minor-image-version,0
 -Wl,@CMakeFiles/test2.dir/objects1.rsp -lkernel32 -luser32 -lgdi32
 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
 (compile .obj)
 c:/tools/unix/mingw.mangled/bin/gcc.exe-o
 CMakeFiles/test1.dir/test1.c.obj   -c M:/tmp/cmake_crash/test4/test1.c
 (link .exe)
 c:/tools/unix/mingw.mangled/bin/gcc.exe
  -Wl,@CMakeFiles/test1.dir/objects1.rsp  -o test1.exe
 -Wl,--out-implib,libtest1.dll.a
 -Wl,--major-image-version,0,--minor-image-version,0  libtest2.dll.a
 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
 -lcomdlg32 -ladvapi32

 In the link .exe step, it references the full name (and full path) of the
 libtest2.dll.a ... if this were a more complex case where a library is
 built in the root, the path could be like ../../../../liblib.dll.a.  Now,
 as a windows target this doesn't matter so much, but when using a toolchain
 file to target android, the full path to the .so gets embedded.





 c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
 --sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm
 -Dtest2_EXPORTS -fPIC
 -Ic:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\include
 -Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\include
 -Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi\include
-o CMakeFiles\test2.dir\test2.c.obj   -c M:\tmp\cmake_crash\test4\test2.c

 c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
 --sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm -fPIC
  -shared  -o libtest2.so CMakeFiles/test2.dir/test2.c.obj
  -Lc:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\lib
  -Lc:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi

 c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
 --sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm
  -Ic:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\include
 -Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\include
 -Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi\include
-o CMakeFiles\test1.dir\test1.c.obj   -c M:\tmp\cmake_crash\test4\test1.c

 c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
 --sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm
 CMakeFiles/test1.dir/test1.c.obj  -o test1
  -Lc:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\lib
  -Lc:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi
  libtest2.so

 see... libtest2.so

 .
 So, since I REALLY need a solution for this; I guess, what I can do is
 stretch out the projects into multiple cmake passes, and treat it more like
 an installed library.



 On Tue, Mar 19, 2013 at 3:05 AM, J Decker d3c...@gmail.com wrote:

 I'm using MinGW Makefiles as a base and a toolchain file.

 I made a (somewhat) simple cmakelists that makes a library, and an
 executable that links against it.

 Without specifying the toolchain, the link command looks something like

 gcc test1.c.obj -o test1 -ltest2
 (hmm no, that's what I want it to say)

 what it does say is more like

 gcc test1.c.obj -o test1 test2.dll.a
 or
 gcc test1.c.obj -o test1 libtest2.so


 can I convince Cmake to generate references to libraries with -l instead
 of the path to the library it linked?

  ; or, the warnings (potential errors?) I'm getting say like...
 /bin/ld.exe: warning: libbag.so, needed by
 ..\..\..\..\libbag.psi++.so, not found (try using -rpath or -rpath-link)
 .../bin/ld.exe: warning: libbag++.so,

Re: [CMake] MinGW Link with -l instead of path?

2013-04-03 Thread J Decker 
alternate target_link_libraries.  Usage is the same.  Test if each library
to link is a target, get that targets path, and break it into parts and add
it to LINK_FLAGS else add with target_link_libraries...

macro(my_target_link_libraries target )
if(CMAKE_COMPILER_IS_GNUCC)
   foreach( target_lib ${ARGN} )
  if( TARGET ${target_lib} )
 get_property( lib_path TARGET ${target_lib} PROPERTY LOCATION)
 if( ${lib_path} MATCHES (.*)/([^/]*)$ )
get_target_property(existing_link_flags ${target}
LINK_FLAGS)
if(existing_link_flags)
set(new_link_flags ${existing_link_flags} -L
${CMAKE_MATCH_1} -l ${target_lib})
else()
set(new_link_flags -L ${CMAKE_MATCH_1} -l
${target_lib})
endif()
set_target_properties( ${target} PROPERTIES LINK_FLAGS
${new_link_flags})
 endif( ${lib_path} MATCHES (.*)/([^/]*)$ )
  else()
 target_link_libraries( ${target} ${target_lib} )
  endif( TARGET ${target_lib} )
   endforeach( target_lib ${ARGN} )
else()
target_link_libraries( ${target} ${ARGN} )
endif()
endmacro()
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW Link with -l instead of path?

2013-04-02 Thread J Decker 
So from the silence, either I described my issue badly, or there isn't a
way?

From the script at the end, when generating 'unix makefiles' with a mingw
environment, or MingW makefiles, these are the gcc commands

(compile .obj)
c:/tools/unix/mingw.mangled/bin/gcc.exe  -Dtest2_EXPORTS  -o
CMakeFiles/test2.dir/test2.c.obj   -c M:/tmp/cmake_crash/test4/test2.c
(link .dll)
c:/tools/unix/mingw.mangled/bin/gcc.exe -shared -o libtest2.dll
-Wl,--out-implib,libtest2.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-Wl,@CMakeFiles/test2.dir/objects1.rsp -lkernel32 -luser32 -lgdi32
-lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
(compile .obj)
c:/tools/unix/mingw.mangled/bin/gcc.exe-o
CMakeFiles/test1.dir/test1.c.obj   -c M:/tmp/cmake_crash/test4/test1.c
(link .exe)
c:/tools/unix/mingw.mangled/bin/gcc.exe
 -Wl,@CMakeFiles/test1.dir/objects1.rsp  -o test1.exe
-Wl,--out-implib,libtest1.dll.a
-Wl,--major-image-version,0,--minor-image-version,0  libtest2.dll.a
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
-lcomdlg32 -ladvapi32

In the link .exe step, it references the full name (and full path) of the
libtest2.dll.a ... if this were a more complex case where a library is
built in the root, the path could be like ../../../../liblib.dll.a.  Now,
as a windows target this doesn't matter so much, but when using a toolchain
file to target android, the full path to the .so gets embedded.





c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
--sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm
-Dtest2_EXPORTS -fPIC
-Ic:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\include
-Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\include
-Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi\include
   -o CMakeFiles\test2.dir\test2.c.obj   -c M:\tmp\cmake_crash\test4\test2.c

c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
--sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm -fPIC
 -shared  -o libtest2.so CMakeFiles/test2.dir/test2.c.obj
 -Lc:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\lib
 -Lc:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi

c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
--sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm
 -Ic:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\include
-Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\include
-Ic:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi\include
   -o CMakeFiles\test1.dir\test1.c.obj   -c M:\tmp\cmake_crash\test4\test1.c

c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe
--sysroot=c:/general/android-ndk-r8c/platforms/android-14/arch-arm
CMakeFiles/test1.dir/test1.c.obj  -o test1
 -Lc:\general\android-ndk-r8c\platforms\android-14\arch-arm\usr\lib
 -Lc:\general\android-ndk-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi
 libtest2.so

see... libtest2.so

.
So, since I REALLY need a solution for this; I guess, what I can do is
stretch out the projects into multiple cmake passes, and treat it more like
an installed library.



On Tue, Mar 19, 2013 at 3:05 AM, J Decker d3c...@gmail.com wrote:

 I'm using MinGW Makefiles as a base and a toolchain file.

 I made a (somewhat) simple cmakelists that makes a library, and an
 executable that links against it.

 Without specifying the toolchain, the link command looks something like

 gcc test1.c.obj -o test1 -ltest2
 (hmm no, that's what I want it to say)

 what it does say is more like

 gcc test1.c.obj -o test1 test2.dll.a
 or
 gcc test1.c.obj -o test1 libtest2.so


 can I convince Cmake to generate references to libraries with -l instead
 of the path to the library it linked?

 ; or, the warnings (potential errors?) I'm getting say like...
 /bin/ld.exe: warning: libbag.so, needed by
 ..\..\..\..\libbag.psi++.so, not found (try using -rpath or -rpath-link)
 .../bin/ld.exe: warning: libbag++.so, needed by
 ..\..\..\..\libbag.psi++.so, not found (try using -rpath or -rpath-link)
 .../bin/ld.exe: warning: libbag.externals.so, needed by
 ..\..\..\..\libbag.psi++.so, not found (try using -rpath or -rpath-link)

 these libraries appear in the actual link line several times, both before
 and after the libraries in question...

 so do I apply the rpath (or rpath-link to the executable or the component
 library... (it's actually a program:lib:lib:lib dependency)
 (I tried both, and it helped, but only for a little while; probably
 because it didn't need to rebuilt, so it wasn't an error. THere aren't any
 unresolved symbols (but could there be?)


 - a cmake to make a lib and executable ---

[CMake] MinGW Link with -l instead of path?

2013-03-19 Thread J Decker 
I'm using MinGW Makefiles as a base and a toolchain file.

I made a (somewhat) simple cmakelists that makes a library, and an
executable that links against it.

Without specifying the toolchain, the link command looks something like

gcc test1.c.obj -o test1 -ltest2
(hmm no, that's what I want it to say)

what it does say is more like

gcc test1.c.obj -o test1 test2.dll.a
or
gcc test1.c.obj -o test1 libtest2.so


can I convince Cmake to generate references to libraries with -l instead of
the path to the library it linked?

; or, the warnings (potential errors?) I'm getting say like...
/bin/ld.exe: warning: libbag.so, needed by ..\..\..\..\libbag.psi++.so,
not found (try using -rpath or -rpath-link)
.../bin/ld.exe: warning: libbag++.so, needed by
..\..\..\..\libbag.psi++.so, not found (try using -rpath or -rpath-link)
.../bin/ld.exe: warning: libbag.externals.so, needed by
..\..\..\..\libbag.psi++.so, not found (try using -rpath or -rpath-link)

these libraries appear in the actual link line several times, both before
and after the libraries in question...

so do I apply the rpath (or rpath-link to the executable or the component
library... (it's actually a program:lib:lib:lib dependency)
(I tried both, and it helped, but only for a little while; probably because
it didn't need to rebuilt, so it wasn't an error. THere aren't any
unresolved symbols (but could there be?)


- a cmake to make a lib and executable ---

cmake_minimum_required(VERSION 2.8)

FILE( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/test1.c int main() { return f(); }
 )
FILE( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/test2.c int f() { return 1; }  )

add_library( test2 SHARED test2.c )
add_executable( test1 test1.c )
target_link_libraries( test1 test2 )

--
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake