gamedevlists-windows

RE: [GD-Windows] Linker hell

[Brian S. <bs...@mi...>]

Ah, the old linking game!

What libs are you linking with?  Have you turned up the link debug spew
(Project->Link->Customize->Print progress messages) to see what code is
referencing the DLL runtime?

Also remember that a line like this in your codebase:

	#pragma comment(lib, "libname")=20

can pull things into your link line unexpectedly.

--brian

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Wednesday, November 07, 2001 11:18 AM
To: gam...@li...
Subject: [GD-Windows] Linker hell

So I'm trying to build a fairly large project, statically linked (no
DLLs), and so far I'm in hell.

First pass: Select all projects and use "Multithreaded Debug" library.
I get conflicts with MSVCRTD.DLL, even though it's not being explicitly
referenced by anything.  I do a DUMPBIN on the modules in question, and
they show they're that their defaultlib is MSVCRTD.LIB even though the
project is showing them as using Multithreaded Debug (LIBCMTD.LIB).
What the hell?

Second pass: Select "No default libraries" and manually specify
LIBCMTD.LIB in the libraries list.  Conflicts go away, but now I get:

LINK : warning LNK4049: locally defined symbol "_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free" imported
LINK : warning LNK4049: locally defined symbol "_memmove" imported
LINK : warning LNK4049: locally defined symbol "_realloc" imported
ogg_static_local.lib(framing.obj) : error LNK2001: unresolved external
symbol __imp__memchr
vorbis_static_d.lib(info.obj) : error LNK2001: unresolved external
symbol _strdup

I'm not using the Ogg Vorbis libs directly, I'm actually compiling the
source files.

What's particularly disturbing is that suddenly it can't find strdup()
or memchr() just because I changed libs?!

Any ideas?

Brian



_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] Linker hell

[Brian H. <bri...@py...>]

Thanks to everyone for their suggestions.  I did a DUMPBIN /ALL on some
of the problematic OBJ files to find out that they were STILL linking to
MSVCRTD.LIB (!).  Grrr.  As it turns out, you can specify the linkage
PER FILE (not just per project).  So even if all your projects are set
to, say, Multithreaded Debug, a file within a project might be set to
Multithreaded Debug DLL (which is what happened in this case).  Once
that was found and I fixed the two files that were set this way (no idea
how they got that way), all problems went away.

*sigh*

Thanks,

Brian

RE: [GD-Windows] Linker hell

[Colin F. <cp...@ea...>]

November 7th, 2001
Wednesday

----- Original Message ----- 
From: "Brian Hook" <bri...@py...>
> Thanks to everyone for their suggestions.  I did a DUMPBIN /ALL on some
> of the problematic OBJ files to find out that they were STILL linking to
> MSVCRTD.LIB (!).  Grrr.  As it turns out, you can specify the linkage
> PER FILE (not just per project).  So even if all your projects are set
> to, say, Multithreaded Debug, a file within a project might be set to
> Multithreaded Debug DLL (which is what happened in this case).  Once
> that was found and I fixed the two files that were set this way (no idea
> how they got that way), all problems went away.

I guess if you do incremental builds, and you changed
the build setting from single-threaded to 
multi-threaded, then the only files to experience
the new settings would be files built after
the settings change.  If none of the files upon
which a source file depends is modified, and
you rarely do a clean build, the stale object
file could stick around!

Maybe changing the setting regarding which
version of the C run-time library to use
should bring up a dialog box that warns
you that a clean rebuild is necessary,
and offers to delete all object files
immediately! :-)

--- Colin

Re: [GD-Windows] Linker hell

[Corrinne Y. <cor...@sp...>]

Ah, the old linking game!

What libs are you linking with?  Have you turned up the link debug spew
(Project->Link->Customize->Print progress messages) to see what code is
referencing the DLL runtime?

Also remember that a line like this in your codebase:

#pragma comment(lib, "libname")

can pull things into your link line unexpectedly.

-- Oh, goodness, forgot those as well! Those are pain in the a**.

-- It would be nice to be just in one place, all libs are linked, and no
where else. One can dream.

-- Well, I am just glad mine is linking and running now, and I had past the
point in my code to have to add more libs (all the major libs are already
inside), condolences to all of you who have to hunt those down. :(