[Lldb-commits] [PATCH] Fix broken test suite on Windows after r223091

[Zachary Turner]

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?

Or is it something else?

On Tue Dec 02 2014 at 4:16:44 PM Greg Clayton <clayborg at gmail.com> wrote:

> Looks like you will need to modify the make rules in:
>
> https://gclayton@llvm.org/svn/llvm-project/lldb/trunk/test/
> make/Makefile.rules
>
> 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.
>
> It is passing "-shared" to clang.exe, but it isn't recognizing it.
>
> > On Dec 2, 2014, at 3:49 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > I actually get errors when doing this.
> >
> > d:\src\llvm\tools\lldb\test\lang\c\shared_lib>make
> CC=d:\src\llvm\build\ninja\bin\clang.exe
> > 'g++' is not recognized as an internal or external command,
> > operable program or batch file.
> > The system cannot find the file specified.
> > The system cannot find the file specified.
> > d:\src\llvm\build\ninja\bin\clang.exe -g -O0 -m32  -fPIC
> -Id:/src/llvm/tools/lldb/test/make/../../include   -c -o main.o main.c
> > d:\src\llvm\build\ninja\bin\clang.exe -g -O0 -m32  -fPIC
> -Id:/src/llvm/tools/lldb/test/make/../../include   -c -o foo.o foo.c
> > d:\src\llvm\build\ninja\bin\clang.exe -g -O0 -m32  -fPIC
> -Id:/src/llvm/tools/lldb/test/make/../../include  -fuse-ld=lld foo.o
> -shared -o "libfoo.so"
> > clang.exe: warning: argument unused during compilation: '-shared'
> > Cannot infer subsystem; assuming /subsystem:console
> > Undefined symbol: C:\Program Files (x86)\Microsoft Visual Studio
> 12.0\VC\lib\libcmt.lib(f:\binaries\Intermediate\vctools\
> crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\nativec\\crt0.obj): _main
> > symbol(s) not found
> > clang.exe: error: linker command failed with exit code 1 (use -v to see
> invocation)
> > make: *** [libfoo.so] Error 1
> >
> >
> > 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++).
> >
> > 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.
> >
> > On Tue Dec 02 2014 at 3:26:32 PM Greg Clayton <clayborg at gmail.com>
> wrote:
> > You will actually want to set this correctly for windows. To find out
> what settings to use use:
> >
> > cd test/lang/c/shared_lib
> > make
> >
> > Then look for the shared library that was created "libfoo.dll"? If so
> your setup would be:
> >
> >
> > ```
> >         elif sys.platform.startswith('windows'):
> >             cls.platformContext = _PlatformContext('PATH', 'lib', 'dll')
> >
> > ```
> >
> > REPOSITORY
> >   rL LLVM
> >
> > http://reviews.llvm.org/D6484
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20141203/c4421625/attachment.html>