[CMake] need help fixing warning message... 3.0

[J Decker]

Without modification
target_link_libraries( ${target} ${target_lib} )

generates a link command like this....

gcc.exe --sysroot=c:/.../platforms/android-14/arch-arm -fPIC -g -D_DEBUG
  -lstdc++ -lgnustl_static -shared  -o
libEditOptions.code.soCMakeFiles/EditOptions.code.dir/editopt.c.obj
  -Lc:\..\platforms\android-14\arch-arm\usr\lib
 -Lc:\...\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi
 ..\..\..\..\libbag.so ..\..\..\..\libbag.psi.so ..\..\..\..\
libbag.externals.so ..\..\..\..\libbag.so ..\..\..\..\libbag.externals.so
-lm -landroid -llog

which results in a library that has the error
   : error: Cannot load library: link_image[1891]:   201 could not load
needed library '..\..\..\..\libbag.so' for 'libEditOptions.code.so'
(load_library[1093]: Library '..\..\..\..\libbag.so' not found)

gcc.exe --sysroot=c:/.../platforms/android-14/arch-arm -fPIC -g -D_DEBUG
  -L C:/general/build/android.2/debug_solution/core -l bag
   -L C:/general/build/android.2/debug_solution/core -l bag.psi
  -L C:/general/build/android.2/debug_solution/core -l bag.externals
  -lstdc++ -lgnustl_static -shared  -o
libbag.video.proxy.client.code.soCMakeFiles/bag.video.proxy.client.code.dir/client.c.obj
  -Lc:\...\platforms\android-14\arch-arm\usr\lib
  -Lc:\...\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi


So my script tests if LOCATION of ${target_lib} is something like....

             get_property( lib_path TARGET ${target_lib} PROPERTY LOCATION)
             if( ${lib_path} MATCHES "(.*)/([^/]*)$" )

which
    lib_path=C:/general/build/android.2/debug_solution/core/
libbag.externals.so

does match....
....
which adds -L (path part) and -l <basename>,   instead of the path name
that doesn't work....

and  adds a dependancy of the targetlib on the target.


(output is from cmake 2.8.10.2; not 3)



On Tue, May 27, 2014 at 3:01 AM, Nils Gladitz <nilsgladitz at gmail.com> wrote:

> On 05/27/2014 11:10 AM, J Decker wrote:
>
>> These result from the libraries resulting from the built sources, not
>> from the sysroot libs or things discovered with find packages.
>>
>>
> I probably don't fully understand the issue but couldn't this easily
> enough be patched in CMake itself (e.g. attached untested patch with
> CMAKE_PLATFORM_NO_SONAME_SUPPORT set to ON)?
>
> Is there an open issue for this?
>
> Nils
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140527/338e3f01/attachment-0001.html>