I think -shared on Windows is ignored.  It's not recognizing it, but it's not what's causing the error either.  I'll have to look into it that separately, but I'm still a little confused about what this PlatformContext code is doing.  Is this our test executable that we're compiling linking against a shared library that we're also compiling, but the shared library is output to a different output directory, so upon building the shared library we set the dylibPath to its folder so that the executable can find it?<br><div><br></div><div>Or is it something else?</div><br><div class="gmail_quote">On Tue Dec 02 2014 at 4:16:44 PM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looks like you will need to modify the make rules in:<br>
<br>
<a href="https://gclayton@llvm.org/svn/llvm-project/lldb/trunk/test/make/Makefile.rules" target="_blank">https://gclayton@llvm.org/svn/<u></u>llvm-project/lldb/trunk/test/<u></u>make/Makefile.rules</a><br>
<br>
to actually handle linking shared libraries on windows. There are a few (5-10) tests that link shared libraries and we want those to work.<br>
<br>
It is passing "-shared" to clang.exe, but it isn't recognizing it.<br>
<br>
> On Dec 2, 2014, at 3:49 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> I actually get errors when doing this.<br>
><br>
> d:\src\llvm\tools\lldb\test\<u></u>lang\c\shared_lib>make CC=d:\src\llvm\build\ninja\<u></u>bin\clang.exe<br>
> 'g++' is not recognized as an internal or external command,<br>
> operable program or batch file.<br>
> The system cannot find the file specified.<br>
> The system cannot find the file specified.<br>
> d:\src\llvm\build\ninja\bin\<u></u>clang.exe -g -O0 -m32  -fPIC -Id:/src/llvm/tools/lldb/test/<u></u>make/../../include   -c -o main.o main.c<br>
> d:\src\llvm\build\ninja\bin\<u></u>clang.exe -g -O0 -m32  -fPIC -Id:/src/llvm/tools/lldb/test/<u></u>make/../../include   -c -o foo.o foo.c<br>
> d:\src\llvm\build\ninja\bin\<u></u>clang.exe -g -O0 -m32  -fPIC -Id:/src/llvm/tools/lldb/test/<u></u>make/../../include  -fuse-ld=lld foo.o -shared -o "libfoo.so"<br>
> clang.exe: warning: argument unused during compilation: '-shared'<br>
> Cannot infer subsystem; assuming /subsystem:console<br>
> Undefined symbol: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\libcmt.lib(f:\<u></u>binaries\Intermediate\vctools\<u></u>crt_bld\SELF_X86\crt\prebuild\<u></u>build\INTEL\mt_obj\nativec\\<u></u>crt0.obj): _main<br>
> symbol(s) not found<br>
> clang.exe: error: linker command failed with exit code 1 (use -v to see invocation)<br>
> make: *** [libfoo.so] Error 1<br>
><br>
><br>
> This probably hints a deeper issue or just something else I haven't gotten around to fixing yet (like maybe it's broken for all C files, and only works for C++).<br>
><br>
> Just so I understand, is this a location where it's supposed to find system libraries, like libc or similar?  Or is this for something else?  Clang is pretty good about automatically finding all required libraries on Windows, so if it's just for that it might not be needed, but if it's a place we're putting our own shared libraries, then maybe we do.<br>
><br>
> On Tue Dec 02 2014 at 3:26:32 PM Greg Clayton <<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>> wrote:<br>
> You will actually want to set this correctly for windows. To find out what settings to use use:<br>
><br>
> cd test/lang/c/shared_lib<br>
> make<br>
><br>
> Then look for the shared library that was created "libfoo.dll"? If so your setup would be:<br>
><br>
><br>
> ```<br>
>         elif sys.platform.startswith('<u></u>windows'):<br>
>             cls.platformContext = _PlatformContext('PATH', 'lib', 'dll')<br>
><br>
> ```<br>
><br>
> REPOSITORY<br>
>   rL LLVM<br>
><br>
> <a href="http://reviews.llvm.org/D6484" target="_blank">http://reviews.llvm.org/D6484</a><br>
><br>
><br>
<br>
</blockquote></div>