In VS2012, I'm statically linking with a precompiled .lib, and need to also use that lib's .pdb file for debugging.
How can I tell the linker that it should use that external pdb file?
If you created the static lib with /ZI or /Zi (see project settings for C/C++ -> General -> Debug Information Format), then the $(IntDir)vc$(PlatformToolsetVersion).pdb file is created. The path is defined by /Fd.
A linker that uses the static library usually also refers to this pdb file. If you link an executable with the static lib and the linker can't find the pdb file you should get the error like this
LNK4099: PDB 'vc1xx.pdb' was not found with 'foo.lib(foo.obj)
So what you want is the default. You may turn on verbose linking to see what happens to your symbols.
Microsoft always ships a PDB file with their static libraries named the same way like the static lib. So you find a libcmt.lib and a libcmt.pdb
Related
When linking my final .exe file I receive error: C1047 The object or library file XX.lib was created by a different version of the compiler than other objects like YY.lib rebuild all objects and libraries with the same compiler.
According to the documentation: https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/fatal-error-c1047?view=msvc-170
It happens when some object files are compiled with /GL or /LTCG flags.
YY.lib is an external library. It is C library, compiled with different version of Visual Studio. But it should be fine. It has no /GL nor /LTCG flag enabled.
XX.lib is another static library. I partially control how it is created. It contains many third-party libraries also inside.
Now I need to somehow figure out which .obj files inside XX.lib were compiled with /GL flag (to remove this flag and fix the issue). Is there any way to find out which .obj files were compiled with the /GL or /LTCG flag enabled without direct access to source/build systems of those libraries ? (I assume it should be possible as linker is able to determine it). But I can't find where this information is stored. I can unpack the static library to individual .obj files. But using e.g. dumpbin I don't see any info about /GL or /LTCG flag.
Given ar libraries and possibly object files, what is the best way to find all of the unresolved external symbols? One possibility is to run the linker and then capture the errors, but sometimes it stops after a certain number of symbols. Is there a better way?
In your mingw-w64 installation's bin directory, along with
the C and C++ compilers, linker and make tool, you should other
programs that make up the GNU binutils.
Several of these (nm, objdump, readelf) can parse the symbol tables of object files or shared or
static libraries. The simplest to use is probably nm. Assuming
that the bin directory is in your PATH, open a command prompt
in the directory containing the libraries or object files your are
interested in and run:
nm -u libfoo.a
or:
nm -u foo.obj
to list the undefined symbols in libfoo.a or in foo.obj.
If these files contain C++ symbols that you want to see demangled then
add -C to the nm options.
These tools all recognize that a static library libfoo.a is just
an archive of object files so nm ... libfoo.a gives you just the
same results as if libfoo.a was replaced with a list of the object
files within it.
I have an android .so(example.so) file which is build with some n number of static libraries(.a files). Is there is any way to find what are the static libraries used to built that .so(example.so) file.
It's not possible to figure out which static libraries were used to build the shared library. Shared libraries aren't a container of their components like static libraries are, but are a linked form of all the object files.
I think the best you can do here is figure out which source files are included, and only if the library hasn't been stripped. You can use readelf -sW libfoo.so, and if it was built from foo.cpp you'll see:
...
18: 00000000 0 FILE LOCAL DEFAULT ABS foo.cpp
...
I have some legacy 'so' file, with the corresponding header, how to make 'a' file out of it
to link with the project ?
(or could I link to 'so' - adding -L/path_to_so/ and -lsomething (assuming so is in /path_to_so and is named libsomething.so does not seem to work - ld complains about missing exports - but they are present in lib (lib is 32bit, -m32 is used, project is 32bit) ?)
I'm not a linux guru, on windows when i have dll and header I'm able to generate lib, that I'm linking with project to use dll - I assume that same is on linux right ?
I have some legacy 'so' file, with the corresponding header, how to make 'a' file out of it to link with the project ?
There is no way to make .a. from .so. On Linux .so get linked directly, no import library is required.
When using the -Wl--whole-archive ... -Wl--no-whole-archive flags with gcc how is it that you veryify that everything links correctlly internal to the library? Also how do you verify that the library can call into other Dynamic libries that are specifed by LD_LIBRARY_PATH or ld(1)?
Assuming you want to build a shared library one solution would be to link a minimal executable against that library as part of you build and see if you get unresolved symbols. Of course this file wouldn't be installed.
The executable you build can really be minimal, for my C++ code I usually use
int main() { }