help needed stdlib not linking

[Gabriel Ivăncescu]

On 12/09/2020 14:11, spaarder wrote:
> Gabriel Ivăncescu schreef op wo 09-09-2020 om 18:30 [+0300]:
>> On 09/09/2020 15:25, spaarder wrote:
>>> Hello,
>>>
>>> I want to contribute to the wonderful Wine project, so I decided to
>>> start with a simple patch for the CreateSymbolicLinkW WINAP in
>>> kernelbase.dll .
>>>
>>> In my patch I use the system() function, which is in the stdlib library.
>>> The linker cannot find this library because of the "-nodefautlibs" in
>>> Makefile.in .
>>> When I remove -nodefaultlibs, all compiles well, but now wineboot (and
>>> probably a _lot_ of other things) are broken, even if I undo my patch.
>>>
>>> Why does removing -nodefaultlibs from wine/dlls/kernelbase/Makefile.in
>>> break so many things? Has it anything to do with @ cdecl system(str)
>>> MSVCRT_system?
>>>
>>> What would be the "proper" (wine) way to solve this?
>>>
>>> Big thanks!
>>>
>>> Hans.
>>
>> Hi Hans,
>>
>> Unfortunately, CreateSymbolicLinkW is actually complicated. There are
>> patches in wine-staging that implement it, so you can take a look there
>> and see why that is so (because Windows also has junction points and so
>> on). See the ntdll-Junction_Points patchset in wine-staging.
>>
>> Now for your question about -nodefaultlibs: the wine dlls that have this
>> flag are compiled as native Windows .DLL PE files. That means they can't
>> use system (unix) functions. kernelbase is one such example: most of the
>> functions in kernelbase are done through ntdll.
>>
>> ntdll is also compiled as PE, but it has a unix library component (to be
>> able to use unix libraries or communicate with the wine server). So in
>> general, the procedure would be to:
>>
>> Implement symbolic links via some ntdll API.
>> Have kernelbase use the ntdll API to implement it.
>>
>> You can see a 'unix' subdir in the ntdll, which is where the unix
>> library is, and it's called through function pointers from the PE module
>> (all files at the root of the dir).
>>
>> Again, the wine-staging patchset might help you in with clues. I'm not
>> that familiar with the details myself, so I apologize if I said
>> something wrong.
>>
>> Someone more knowledgeable might clarify it better, if they have the time.
> 
> Thank you for your answer Gabriel, it helped me a lot! I looked at the 
> patch in staging, and I noticed it is HUGE and COMPLICATED.

Yeah, it's complicated as I said. On Windows, you have both junctions 
(which can only point to directories) and symbolic links (which can 
point to both files and directories). AFAIK, a symlink also remembers 
whether it points to a directory or to a file, even if the target 
doesn't exist (so you can't inspect the target to report whether it's a 
dir or file). All of these things must be implemented using some 
trickery (such as specially encoding the underlying unix symlink and 
translating it back when requested by a Windows app, giving it the 
information).

Another potential problem is what happens when you move the prefix. What 
about absolute symlinks? Clearly, on Windows you can store absolute 
symlinks to drives like `D:\somedir` and moving the symlink within the 
Windows filesystem will still point to the same place. This works on 
Wine if you keep absolute unix symlinks, but it creates another problem 
if you move the wine prefix itself, because then the symlink will be dead.

You have to take into account all of these matters. Your solution also 
uses a system command to do it, which should only be a last resort in 
extreme cases (such as when you need a setuid binary), instead of simply 
calling unix library functions, which is much faster and reliable.

Now, if you're interested in just making use of this functionality, is 
there a reason you can't just use the wine-staging patch? Is it wrong in 
some cases you need? You might consider bringing those issues up and/or 
fixing them instead in the wine-staging patchset.

Your patch is obviously wrong for the purposes of the Wine project and 
is what we call a "hack" since it clearly doesn't match Windows 
behavior. Keep in mind that just because it works for you doesn't mean 
there's not some obscure app somewhere that relies on Windows specific 
symbolic link behavior. That's why the wine-staging patch is so 
complicated, and it's still not ready yet for upstream.