How to declare duplicate lib entries?

[Ficko]

I did run into several times this problem but can't figure out a solution despite it may be something obvious.

I wanna use a specific function from a specific lib, which is happens to be in an other lib as well (different version same name).

How can I specify from which lib the function should be linked?

Like you generate a current "ntdll.lib" it will contain several exports, which will conflict with "msvcrt.lib" or "crtdll.lib" like "_snprintf" etc.

You propable don't wanna link with "ntdll._snprintf" because it is not the same as "msvcrt._snprintf" but it is what gone happen.

How can you specify that "msvcrt.lib" is the one you need?

[sapero]

It depends on the order you link ($use) the libs. Try first including the msvcrt, then ntdll.

Code Select Expand

$use "mscvrt.lib"
$use "ntdll.lib"
The linker will search first in mscvrt.lib, then in ntdll.lib.

If you have a project, add this code to all source files, or add the libs to project (mscvrt.lib first).
If this does not help, you can always modify (using any hex editor) the first string-table in ntdll.lib by renaming the first found api and __imp_api.

[Ficko]

Thanks Sap!

This is exactlly how I  did it till now I hopped there is some "undocumented" trick like "Declare Sub RtlMoveMemory Lib "kernel32" ( _....." like in VB.

It is quit a mess if you use sveral functions accross the libs declaration sequence dosn't help in such a case.

Patching the lib(s) is the only way, which is extramelly dirty.

[sapero]

Nope, VB uses LoadLibrary and GetProcAddress. Ebasic linker may not always search from the beginning of lib-list, if you call a function from ntdll, it (probably) sets the ntdll.lib as the current library, and starts searching next symbol from ntdll.lib instead from the first library from internal list.

This is a copy from psapi header from windows 7:

//
// This change is to help downlevel applications with psapi symbol resolution
// Psapi APIs were moved into kernel32.lib to fix a perf bug. Since kernel32.lib and
// psapi.lib both existed downlevel,we need to make sure that downlevel apps resolve to
// psapi.lib,not kernel32.lib. Problem: The linker does not necessarily start at
// the top of the list of TARGETLIBS when resolving symbols. It simply asks for symbols
// where ever it is in the list and keeps going until the symbol is resolved or we cycle
// through the entire list. In an attempt to get correct symbol resolution,you need to put the
// psapi.lib* ust* before the kernel32.lib in the TARGETLIBS macro. Otherwise,
// the linker could incorrectly resolve any psapi APIs to kernel32.lib,which causes
// a build break.

You could optionally move all functions that do not call ntdll apis to the top (of source code), so the linker will respect your order of included libraries.