Linker warning

Started by
5 comments, last by wasd 16 years, 6 months ago

warning LNK4254: section '.CRT' (40000040) merged into '.data' (C0000040) with different attributes
The code compiles and runs fine - the reason I'm getting this error is because I'm using an older version of msvcrt.lib. I'd like to know more about this - precisely why I'm getting this warning and if there's anything I can/could/should do to rectify this. As best I can tell (and I'm guessing here) 4 and C are version numbers or something similar. What I know is that I can't find the hex string 40000040 inside msvcrt.lib. I did some Googling, but couldn't really find anything useful. Should I worry about this or can I just supress it? [Edited by - irreversible on October 25, 2007 6:15:20 PM]
Advertisement
It's an address, not a version number AFAIK.

Are you statically linking against a specific version of the CRT?
Yes, but I'm not sure which one.

The bottom line is, it's an older version - judging by the size, probably VC4 or something like that. But it's just a guess.

The version clash is intentional - I'd now just like to fit the CRT as snugly as possible with the current code.
Here's a solution (I'm presenting my chain of action for clarity). Please comment on it:

1) I fount this page, which says:

At this point, linking produces the following warning:corelibc.lib(crt0init.obj) : warning LNK4254: section '.CRT' (40000040) merged into '.data' (C0000040) with different attributesThat warning can be eliminated by setting Subsystem = WindowsCE (/SUBSYSTEM:WINDOWSCE)So the linker is happy, but regardless of whether BaseAddress is blank orBaseAddress = 0x00010000			(the value adopted by the migration wizard),


2) So I set the subsystem to WindowsCE. This produced a new error claiming that the DLL has no entry point although it did get rid of the merger warning. Fair enough.


error LNK2001: unresolved external symbol __DllMainCRTStartup
[\code]

Furthermore I wasn't comfortable with the subsystem being WindowsCE as I don't really grasp what it is (I understand it's for portable devices)

3) so I set the subsystem back to windows and no entry point option to true, which generated some fuss because static variables were no longer being initialized.

4) so I set up my own custom entry point and added the minimum required number of initialization functions from TLIBC




It now compiles without warnings, but includes my own startup code. What I'm not sure about is why this code isn't clashing with functions already defined in msvcrt.lib. After all, I'm defining my own version for functions like _init_file() an the like.
Wait, let's take a step back here... What type of exe are you compiling (DLL, Win32 exe, console exe, etc), and what compiler? Why are you using an old version of msvcrt.lib in the first place? That's bound to cause problems.

Also, a little off topic, the 40000040 and C0000040 numbers are the attributes for the two segments (32-bit bitmask).
I'm compiling a DLL using VS9. I'm using an older version of msvcrt.lib to avoid distributing msvcr90.dll along with the DLL, which cannot really be expected to exist on any given system out there. The current version I'm using links very nicely to msvcrt.dll (which is forwarded to by msvcrt40.dll in system32).

What kinds of problems might I expect? Because linkage-wise I haven't seen any real problems apart from the fact that the older CRT doesn't have the safe versions for string functions and such.
MSDN is your friend.

Quote:When targeting x86 machines and Windows CE targets (ARM, MIPS, SH4, and Thumb) with Visual C++ 2005, the .CRT section is now read only. If your code depends on the previous behavior (.CRT sections are read/write), you could see unexpected behavior.


Doesn't look like there's any way to disable the merging, so I guess you just have to make sure that your code doesn't try to write to anything in the CRT section.

This topic is closed to new replies.

Advertisement