[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Patchless modification of Lua source code
- From: Philippe Verdy <verdy_p@...>
- Date: Sat, 24 Nov 2018 14:39:22 +0100
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.
On Sat, 24 Nov 2018 13:04:50 +0100
Viacheslav Usov <firstname.lastname@example.org> 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.