vs2010: warning LNK4254: section 'ATLP' (50000040) merged into '.rdata' (40000040) with different attributes


I see atlperf.h creates a section as readonly-shared. However I don't understand why is it needed. I've dumpbin'ed my dll compiled with vs2005 and it looks like it was always 40000040, just with no warning.
If I specify /section:.rdata,rs for linker it give another warning: warning LNK4223: the SHARED (S) attribute specified for section '.rdata' is ineffective without the WRITE (W) attribute
Is the "shared" really needed for ATLP section?


vvdb wrote May 4, 2010 at 12:25 PM

I get the same linker warning here.
It's not clear how to solve this problem.
Probably due to the following:

if !defined(_M_IA64)

pragma comment(linker, "/merge:ATL=.rdata")


being defined in the standard ATL files, but NOT in the ATLServer files.

I tried adding it around i.e. #include <atlhttp.h>, but it doesn't help.

Any help in solving this problem is greatly appreciated.

wrote May 5, 2010 at 12:12 AM

ReenaG wrote Jun 15, 2010 at 1:13 AM

I am having the same problem. Since this is a warning and not an error is it Ok to ignore it?

LISTECH wrote Jul 2, 2010 at 3:57 AM

I'm getting a very similar warning but with the section 'ATLS'. Any help in solving this problem would be greatly appreciated.

wrote Jul 2, 2010 at 3:57 AM

wrote Jul 4, 2010 at 6:14 AM

wrote Sep 21, 2010 at 9:05 PM

Paul7 wrote Oct 19, 2010 at 12:24 AM

The same issue here. Lots of warnings when linking. This could be a problem with VC ATL includes. In VS 2008 atlbase.h the part of the file with pragmas is compiled conditionally.
$if defined(_M_IA64) || defined(_M_IX86) ...
In VS 2010 the same declaration in atlbase.h is not conditional so it is included in 64 bit compilation.
For now I prefer to ignore these warnings. Maybe in the next VS 2010 service pack it will be fixed.

mloskot wrote Dec 1, 2010 at 3:54 PM

It looks to me there is conflict between read-only and shared attributes of the declared sections and merging them with .rdata.

I have asked related question here http://social.msdn.microsoft.com/Forums/en-US/vcmfcatl/thread/4763bc2d-0e86-45e9-bfe4-ddaa735e5ad5

wrote Dec 22, 2010 at 2:37 PM

wrote Dec 30, 2010 at 8:40 PM

wrote Feb 22, 2011 at 6:59 PM

pally_sandher wrote Aug 19, 2011 at 5:25 PM

Still seeing this with SP1 for VS2010 applied.

research_opencs wrote Nov 7, 2011 at 4:31 PM

I have a similar problem with "ATLS" section and VC2010.

Based on the comments posted by vvdb I discovered that this error is caused because the .rdata in VC2010 does not accept the attribute shared required by ATLS (dumpbin):

.rdata name
2651D virtual size
FC000 virtual address (100FC000 to 1012251C)
26600 size of raw data
AA000 file pointer to raw data (000AA000 to 000D05FF)
   0 file pointer to relocation table
   0 file pointer to line numbers
   0 number of relocations
   0 number of line numbers
40000040 flags
     Initialized Data
     Read Only
While the ATLS defines the attribute shared:

ATLS name
 208 virtual size
12B000 virtual address (1012B000 to 1012B207)
 400 size of raw data
D3E00 file pointer to raw data (000D3E00 to 000D41FF)
   0 file pointer to relocation table
   0 file pointer to line numbers
   0 number of relocations
   0 number of line numbers
50000040 flags
     Initialized Data
     Read Only
In order to solve this, I modified the header "atlisapi.h" to remove the merge if _MSC_VER is greater or equal to 1600 (VC2010). This fixed the problem and appears to be working with no major problems except for the existence of an extra segment.

The modification is as follows:

if !defined(_M_IA64)

#if _MSC_VER < 1600 
    #pragma comment(linker, "/merge:ATLS=.rdata")


It is possible that the same approach will solve the error detected with the ATL section as well because the problem appears to be the same.

More details about the sections can be found in http://msdn.microsoft.com/en-us/library/sf9b18xk.aspx

AlanChen wrote May 24, 2012 at 11:02 AM

Just Ignore it , nobody fix this!

property: linker: commandline--> Ignore:4254

wrote Feb 14, 2013 at 8:57 PM

Yalos wrote May 30, 2014 at 11:56 AM

I think the solution suggested by research_opencs is in the right direction. However, there is room to improve. If we look immediately above the merge directive we see the real problem:
// definitions of data segments and _HANDLER_ENTRY delimiters

pragma section("ATLS$A", read, shared)

pragma section("ATLS$Z", read, shared)

pragma section("ATLS$C", read, shared)

Here we see ATLS declared as read and shared. This is then merged into rdata which is only read and we see the warning. Now, if we run of win32 (either 32 or 64 bits) there is no meaning for the shared attribute. Reading the documentation from here http://msdn.microsoft.com/en-us/library/50bewfwa.aspx we see that shared means: “Shares the section among all processes that load the image.”. At least under 32 this is impossible due to memory protection between processes. We will have 1 copy of this section for each process loading this section.
Indeed, if one looks into the atlbase.h what comes with VS 2010 she will see the same construct, declared as follows:

pragma section("ATL$__a", read)

pragma section("ATL$__z", read)

pragma section("ATL$__m", read)

We see here the, at a more recent date someone from Microsoft fixed this problem by removing the shared attribute. We can guess that this happened sometime between VS 2005 and VS 2010.
Instead of conditioning the merge, I would suggest either removing the shared at all (it works for Microsoft) or conditioning the section declaration as follows:

if _MSC_VER < 1600

pragma section("ATLS$A", read, shared)

pragma section("ATLS$Z", read, shared)

pragma section("ATLS$C", read, shared)


pragma section("ATLS$A", read)

pragma section("ATLS$Z", read)

pragma section("ATLS$C", read)


For my immediate purposes the solution above is an overkill (I use VS2010) and I just deleted the shared attribute but for this code repository I would say this is the correct answer.

In closing, I think the “solution” from AlanChen was the best: just ignore it. The section will be merged and there is no side effect that I can imagine (no meaningful shared attribute on win32)