Which lib is _DllMainCRTStartup found in?

Which lib is _DllMainCRTStartup found in?

• prudhvi

  Is linking in corelibc.lib causing you a specific problem
  

• Graham Parker

  Does your definition of DllMain match the following:
  
  

  extern "C" BOOL WINAPI DllMain(HANDLE hInstance, DWORD dwReason, LPVOID lpReserved)
  
  
  
  That's the definition generated by our default ATL DLL project wizard and I know that get's picked up correctly.  Is DllMain included in your ugl.def file   If so you should try removing it, as I've never seen that done, and I'm not sure what that will do.
  
  I don't know why corelibc.lib is exporting the symbol DllMain, but I'm following up with the OS guys to find out, as it strikes me as odd; however, this has been occuring since at least CE4.2, so I don't think it should actually be a problem and we have not encountered it ourselves on the VSD team.

  
  

• Loknar - DBA

  Just as a point of clarification, this is not an MFC project and has no C++ in it. It is strictly C and JNI code for the purpose of building a C-language dll file.
  

• JELT

  Thanks for the quick reply, but that makes me curious: we didn't need corelibc.lib to link in eVC++. Has the location of _DllMainCRTStartup changed Is there a way to get it without corelibc.lib
  
  Thanks,
  Zack

  
  

• MartinBatsman

  The symbol _DllMainCRTStartup is provided by corelibc.lib.
  

• HLDev

  Yes, linking against corelibc.lib causes a problem because it defines DllMain. We need to use our definition of DllMain, and the one in corelibc.lib gets grabbed first, which kills our whole build.
  The way I understand it, it would work if I could get the linker to pull in our library before corelibc. I verified this by making DllMain a separate class. In that case, the project successfully builds, but uses the wrong DllMain (the one in corelibc.lib).
  
  So my main question is, is there a way to force my lib to be included first, or to get _DllMainCRTStartup without corelibc.lib I mention excluding it because we didn't include it at all in the eVC++ version of the project.
  It's not a problem to include corelibc.lib if you can help me get the linker to use the right DllMain.
  
  The command line to the linker is included below.
  
  Thanks,
  Zack
  
  
  
  /OUT:"ARMV4Dbg/ugl.dll" /INCREMENTAL /NOLOGO /LIBPATH:"ugl_wince_port"
  /LIBPATH:"../external/lib" /DLL /MANIFEST:NO /NODEFAULTLIB:"kernel32.lib"
  /NODEFAULTLIB:"oldnames.lib" /DEF:".\ugl.def" /DEBUG /PDB:"Pocket PC 2003 (ARMV4)\Debug/ugl.pdb" /SUBSYSTEM:WINDOWSCE /STACK:65536,4096 /ENTRY:"_DllMainCRTStartup" /BASE:"0x00100000" /IMPLIB:"Pocket PC 2003 (ARMV4)\Debug/ugl.lib" /MACHINE:ARM /ERRORREPORT:PROMPT corelibc.lib coredll.lib secchk.lib aygshell.lib commctrl.lib Ole32.lib ".\pocket pc 2003 (armv4)\debug\ugl_wince_port.lib" "..\..\..\imagesupport\evs-projects\libpng\pocket pc 2003 (armv4)\debug\libpng.lib" "..\..\..\imagesupport\evs-projects\zlib\pocket pc 2003 (armv4)\debug\zlib.lib" "..\..\..\imagesupport\evs-projects\giflib\pocket pc 2003 (armv4)\debug\giflib.lib" "..\..\..\imagesupport\evs-projects\libjpeg\pocket pc 2003 (armv4)\debug\libjpeg.lib" /ALIGN:4096 /subsystem:$(CESubsystem) /MACHINE:ARM /verbose:lib
  

• neuralsea8

  Thanks. That's all helpful information.
  
  My (hopefully) last question regarding this issue, then, is this:
  
  Is there a smooth way to put the libraries in the appropriate order on the command line using the built-in tools in the VS 2005 IDE The only way that I have found is to list them out in order under Linker->input->additional dependencies, and that only works if I use the full path to libraries that aren't MS defaults.
  Does the current tooling provide an effective way to control the order of library imports, and if not, will this be fixed in the final release
  
  Thanks for all the helpful feedback,
  Zack
  

• DMOORE

  Got the following from the OS guys:
  
  "Holdover from the desktop port.  The idea was that if you supply your own DllMain, the OBJ containing it on the command line overrides the one pulled in from a LIBC.LIB.  If you don't supply it, the LIBC version is pulled in.  VC still does this.

   

  We've had problems here since we rarely link from OBJs.  Linking from LIBs creates an ambiguity.  The solution is usually to add /INCLUDE:DllMain on the linker command line and put CORELIBC.LIB last."
  
  Hopefully that will do the trick for you.

  
  

• Pablo A Castillo

  I'm still trying to figure this one out. Anybody get a good idea
  
• Which lib is _DllMainCRTStartup found in?