lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

There's no elephant here, Windows is not different from Unix or other POSIX-compatible systems when it handles simple libraries or shared libraries (DLLs). Not all POSIX systems support shared libraries, but in that case, it is only the possibility of created **non-shared** libraries that can produce unspecified behavior, because **non-shared** libaries are unordered collections of units (the order is unpredictable), so they cannot contain multiple distinct units defining the same exported symbol.
This problem does not occur with shared libaries/DLLs whose internal dependencies are fully resolved and the rest of their unresolved symbols (that are not part of the list of their own exported symbols) is restricted to be a set of unique identifiers: the order or resolution is fully specified with shared libraries.

Le sam. 24 nov. 2018 à 14:23, Ivan Krylov <> a écrit :

On Sat, 24 Nov 2018 13:04:50 +0100
Viacheslav Usov <> wrote:

> We have an elephant in the room here, and let me just name it:
> Windows. Once somebody demonstrates similar techniques on Windows, we
> could talk about real-world portability.

For what it's worth, Sean's experiment can be reproduced on MSVC 2010:

 >cl /c main.c
 >cl /c func1.c
 >cl /c func2.c
 >cl /c myfunc2.c
 >lib /out:func.lib func1.obj func2.obj
 >link /out:main.exe main.obj myfunc2.obj func.lib

> First, other libraries that the executable depends on will not have
> been linked statically to the same "replacement" functions, so they
> will have to resort to the "original" dependencies. Your program, as
> whole, may end up using different versions of the same set of
> functions simultaneously.

I've certainly encountered such nasty cases in the past when I was
learning C, but right now I cannot produce such an example that would
also be concise and easy to reproduce. If you have one handy, I would be
glad to test it on Windows, too.

Best regards,