Not sure why i wasn't getting this earlier, but yea it makes sense now.  <br><br><div class="gmail_quote">On Tue Dec 02 2014 at 4:42:32 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"><br>
> On Dec 2, 2014, at 4:37 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> 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>
><br>
> Or is it something else?<br>
<br>
A Makefile for a test might contain:<br>
<br>
LEVEL = ../../../make<br>
<br>
DYLIB_NAME := foo<br>
DYLIB_C_SOURCES := foo.c<br>
C_SOURCES := main.c<br>
CFLAGS_EXTRAS += -fPIC<br>
<br>
include $(LEVEL)/Makefile.rules<br>
<br>
The means a shared library needs to be created named "foo" and the sources for the shared library are foo.c.<br>
<br>
Most platforms include an automatic prefix to and libraries like:<br>
linux and freebsd is: "lib" + DYLIB_NAME + ".so"<br>
macosx is: "lib" + DYLIB_NAME + ".dylib"<br>
<br>
So this setting it accounting for how the makefiles create a shared library from a basename, and also it specifies the environment variable that is used in a main executable to say where to look for shared libraries.<br>
<br>
So this setting just tries to set these things correctly for the current system.<br>
<br>
Because this test will launch the "a.out" and load the "libfoo.dylib" using the correct environment variable for you system.<br>
<br>
Greg<br>
<br>
> On Tue Dec 02 2014 at 4:16:44 PM Greg Clayton <<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>> wrote:<br>
> 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>
<br>
</blockquote></div>