Marie-Christine Vallet wrote:
> Juan Sanchez wrote:
>> Could this be an issue with linker order? Most linkers are one pass.
>> The library containing the undefined references should be on the linker
>> line before the library containing the symbols, or vice-versa (I keep
>> forgetting).
>>
>>
> The symbols are part of the newly created library, and they are only
> reference in the executable
>> Do the libraries contain the symbols that they should? Use whatever the
>> nm equivalent on mac os is to check.
nm is a unix tool, which google claims to exist on the mac, which tells
you the name of any symbols that are referenced (but undefined), or are
defined somewhere in the objects of an archive file or binary.
If you have a C++ project, you can do:
nm foo.a | c++ filt
to see the human readable version of the symbols in your archive.
If your linker complains about an undefined symbol, you can go looking
for the symbol in the archive you think it belongs to.
For example:
~> nm ctest/hello | grep main
U __libc_start_main@@GLIBC_2.0
08048424 T main
Says that main is defined in my binary, but the symbol
__libc_start_main@@GLIBC_2.0 is referenced and undefined.
If it is in the appropriate place, you then need to look at the linker
order on the link line.
Regards,
Juan
>>
> what is nm?
>> Regards,
>>
>> Juan
>>
>>
>
> _______________________________________________
> CMake mailing list
> [email protected]
> http://www.cmake.org/mailman/listinfo/cmake
>
>
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
