So, you are building an executable with a funciton called dllmain? I would still expect to see all object files being fed to the linker, but it may not be part of the command-line, as it may be part of an indirect input.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Hi Elysia,
The reason why I am doing this, is because all our previous discussion is just theory discussion -- i.e. linker will search obj files before searching lib files. So, I want to make my hands dirty to make some test to show obj files are input before lib or something.
BTW: do you have any practice for us to illustrate (prove) your point -- linker will search obj files before searching lib files?
Hi Mats,
"you are building an executable with a funciton called dllmain"
No, I am building the dll itself. I think if you tried in your own environment, I think you will find similar issues -- no object files as input to linker.
regards,
George
Really?Code:/OUT:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_link1.exe"
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
My mistake, Mats!
Sorry, here is the correct information. You can see still no main.obj.
/OUT:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.dll" /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"Debug\test_dll_link1.dll.intermediat e.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"d:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.pdb" /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
regards,
George
The command line shown in the project properties is the result of your project settings. The actual input files are added when building.
You need to look at the log of the build process to find the real linker command line.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Right, I haven't got Visual Studio at work, so I can't say where the main.obj would be, but are you saying that your text is not being output when the DLL is "started"?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
You are correct, CornedBee!
Cool! Here is the build log and seems main.obj is appended as the end of linker input.
So, coming back to my original question, why do you think user provided DllMain (in main.obj) will be selected to be linked other than using CRT default one -- because obj has higher priority than lib?
--------------------
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000168926972.rsp" with contents
[
/Od /D "_WINDLL" /D "_MBCS" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /c /ZI /TP ".\main.cpp"
]
Creating command line "cl.exe @"d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000168926972.rsp" /nologo /errorReportrompt"
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000268926972.rsp" with contents
[
/OUT:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.dll" /DLL /MANIFEST /MANIFESTFILE:"Debug\test_dll_link1.dll.intermediat e.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.pdb" /DYNAMICBASE /NXCOMPAT /MACHINE:X86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
".\Debug\main.obj"
]
Creating command line "link.exe @"d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000268926972.rsp" /NOLOGO /ERRORREPORT:PROMPT"
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000368926972.rsp" with contents
[
/outputresource:"..\Debug\test_dll_link1.dll;#2" /manifest
".\Debug\test_dll_link1.dll.intermediate.manif est"
]
Creating command line "mt.exe @"d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000368926972.rsp" /nologo"
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\BAT0 0000468926972.bat" with contents
[
@echo Manifest resource last updated at %TIME% on %DATE% > ".\Debug\mt.dep"
]
Creating command line """d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\BAT0 0000468926972.bat"""
--------------------
Hi Mats,
I have found in the build log, other than in the linker command line window, main.obj is added. And it is at the end of the command line. So the theory of sequence matters is not correct.
So, what is your point? Function in obj always has higher priority than in lib?
regards,
George
or something similar. Im assuming though that rather than it being in some hidden headr file, that it actually just adds some generic code to the DLL. Now that I think about it Im almost positive it would have to be in the linker itself.Code:#ifndef DllMain BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: break; } return TRUE; } #endif
Last edited by abachler; 02-13-2008 at 09:46 AM.
I guess MS linker works a bit differently than the gnu ld then - because there the order is definitely important. But it makes some sense to perform lib resolution AFTER the object files "enforced", as you do want all object files always, whilst lib content is optional.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
hmm, Ive never tried overloading a function that was in a library Im linking to, perhaps that is how they do it?
Thats probably how its done then, some required lib for making a dll contains the generic DllMain, and the logic that subverts overloaded lib functions handles that one the same way. Oh now it almost makes me want to write my own compiler... almost.
Why would the generic DllMain have to be in some library? The linker might just have it hardcoded. We don't know, because MS doesn't document this stuff. But it also shouldn't matter.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law