No subject


Tue Jan 15 14:41:49 EST 2013


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, at 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, at 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 <d3ck0r at 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_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 )
>
> ----------------------
>
>

--f46d0447f3f8d8794c04d9633c43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So from the silence, either I described my issue badly, or=
 there isn&#39;t a way?<div><br></div><div>From the script at the end, when=
 generating &#39;unix makefiles&#39; with a mingw environment, or MingW mak=
efiles, these are the gcc commands....</div>
<div><br></div><div style>(compile .obj)</div><div><div>c:/tools/unix/mingw=
.mangled/bin/gcc.exe =A0-Dtest2_EXPORTS =A0-o CMakeFiles/test2.dir/test2.c.=
obj =A0 -c M:/tmp/cmake_crash/test4/test2.c</div><div><div style>(link .dll=
)</div>
<div>c:/tools/unix/mingw.mangled/bin/gcc.exe =A0 =A0 -shared -o libtest2.dl=
l -Wl,--out-implib,libtest2.dll.a -Wl,--major-image-version,0,--minor-image=
-version,0 -Wl, at CMakeFiles/test2.dir/objects1.rsp -lkernel32 -luser32 -lgdi=
32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32=A0<=
/div>
<div><div>(compile .obj)</div><div></div><div>c:/tools/unix/mingw.mangled/b=
in/gcc.exe =A0 =A0-o CMakeFiles/test1.dir/test1.c.obj =A0 -c M:/tmp/cmake_c=
rash/test4/test1.c</div><div><div style>(link .exe)</div><div>c:/tools/unix=
/mingw.mangled/bin/gcc.exe =A0 =A0 =A0-Wl, at CMakeFiles/test1.dir/objects1.rs=
p =A0-o test1.exe -Wl,--out-implib,libtest1.dll.a -Wl,--major-image-version=
,0,--minor-image-version,0 =A0libtest2.dll.a -lkernel32 -luser32 -lgdi32 -l=
winspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32=A0</div>
<div style><br></div></div></div></div><div style>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 co=
uld be like ../../../../liblib.dll.a. =A0Now, as a windows target this does=
n&#39;t matter so much, but when using a toolchain file to target android, =
the full path to the .so gets embedded.....=A0</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=3D=
"gmail_extra">
c:\general\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\wi=
ndows\bin\arm-linux-androideabi-gcc.exe --sysroot=3Dc:/general/android-ndk-=
r8c/platforms/android-14/arch-arm -Dtest2_EXPORTS -fPIC -Ic:\general\androi=
d-ndk-r8c\platforms\android-14\arch-arm\usr\include -Ic:\general\android-nd=
k-r8c\sources\cxx-stl\gnu-libstdc++\4.6\include -Ic:\general\android-ndk-r8=
c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi\include =A0 =A0-o CMakeFil=
es\test2.dir\test2.c.obj =A0 -c M:\tmp\cmake_crash\test4\test2.c</div>
<div class=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra"><div =
class=3D"gmail_extra">c:\general\android-ndk-r8c\toolchains\arm-linux-andro=
ideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe --sysroot=3Dc=
:/general/android-ndk-r8c/platforms/android-14/arch-arm -fPIC =A0 =A0-share=
d =A0-o libtest2.so CMakeFiles/test2.dir/test2.c.obj =A0-Lc:\general\androi=
d-ndk-r8c\platforms\android-14\arch-arm\usr\lib =A0-Lc:\general\android-ndk=
-r8c\sources\cxx-stl\gnu-libstdc++\4.6\libs\armeabi=A0</div>
<div class=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra"><div =
class=3D"gmail_extra">c:\general\android-ndk-r8c\toolchains\arm-linux-andro=
ideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe --sysroot=3Dc=
:/general/android-ndk-r8c/platforms/android-14/arch-arm =A0-Ic:\general\and=
roid-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 =A0 =A0-o CMake=
Files\test1.dir\test1.c.obj =A0 -c M:\tmp\cmake_crash\test4\test1.c</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_extra">c:\general\android-ndk-r8c\toolchains\arm-linux-androideab=
i-4.6\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe --sysroot=3Dc:/gen=
eral/android-ndk-r8c/platforms/android-14/arch-arm =A0 =A0 CMakeFiles/test1=
.dir/test1.c.obj =A0-o test1 =A0-Lc:\general\android-ndk-r8c\platforms\andr=
oid-14\arch-arm\usr\lib =A0-Lc:\general\android-ndk-r8c\sources\cxx-stl\gnu=
-libstdc++\4.6\libs\armeabi =A0libtest2.so=A0</div>
<div class=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra">see..=
. libtest2.so=A0<br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">.....</div><div class=3D"gmail_extra" style>So, since I RE=
ALLY need a solution for this; I guess, what I can do is stretch out the pr=
ojects into multiple cmake passes, and treat it more like an installed libr=
ary.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
br><div class=3D"gmail_quote">On Tue, Mar 19, 2013 at 3:05 AM, J Decker <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:d3ck0r at gmail.com" target=3D"_blank">d3=
ck0r at gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I&#39;m using MinGW Makefiles as a base and a toolchain fi=
le.<div>
<br></div><div>I made a (somewhat) simple cmakelists that makes a library, =
and an executable that links against it.</div><div><br></div><div>Without s=
pecifying the toolchain, the link command looks something like</div>
<div><br></div><div>gcc test1.c.obj -o test1 -ltest2 =A0=A0</div><div>(hmm =
no, that&#39;s what I want it to say)=A0</div><div><br></div><div>what it d=
oes say is more like</div><div><br></div><div>gcc test1.c.obj -o test1 test=
2.dll.a</div>

<div>or</div><div>gcc test1.c.obj -o test1 libtest2.so</div><div><br></div>=
<div><br></div><div>can I convince Cmake to generate references to librarie=
s with -l instead of the path to the library it linked?</div><div><br>
</div>
<div>; or, the warnings (potential errors?) I&#39;m getting say like...</di=
v><div><div>..../bin/ld.exe: warning: libbag.so, needed by ..\..\..\..\libb=
ag.psi++.so, not found (try using -rpath or -rpath-link)</div><div>.../bin/=
ld.exe: warning: libbag++.so, needed by ..\..\..\..\libbag.psi++.so, not fo=
und (try using -rpath or -rpath-link)</div>

<div>.../bin/ld.exe: warning: <a href=3D"http://libbag.externals.so" target=
=3D"_blank">libbag.externals.so</a>, needed by ..\..\..\..\libbag.psi++.so,=
 not found (try using -rpath or -rpath-link)</div></div><div><br></div><div=
>
these libraries appear in the actual link line several times, both before a=
nd after the libraries in question...</div>
<div><br></div><div>so do I apply the rpath (or rpath-link to the executabl=
e or the component library... (it&#39;s actually a program:lib:lib:lib depe=
ndency)</div><div>(I tried both, and it helped, but only for a little while=
; probably because it didn&#39;t need to rebuilt, so it wasn&#39;t an error=
. THere aren&#39;t any unresolved symbols (but could there be?)</div>

<div><br></div><div><br></div><div>----- a cmake to make a lib and executab=
le -----------</div><div><br></div><div>cmake_minimum_required(VERSION 2.8)=
</div><div><div><br></div><div>FILE( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/test=
1.c &quot;int main() { return f(); } &quot; )</div>

<div>FILE( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/test2.c &quot;int f() { return=
 1; } &quot; )</div><div><br></div><div>add_library( test2 SHARED test2.c )=
</div><div>add_executable( test1 test1.c )</div><div>target_link_libraries(=
 test1 test2 )</div>

<div><div><br></div><div>----------------------</div></div></div><div><br><=
/div>
</blockquote></div><br></div></div></div>

--f46d0447f3f8d8794c04d9633c43--


More information about the CMake mailing list