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

[Zachary Turner]

Not sure why i wasn't getting this earlier, but yea it makes sense now.

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

>
> > On Dec 2, 2014, at 4:37 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > 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?
>
> A Makefile for a test might contain:
>
> LEVEL = ../../../make
>
> DYLIB_NAME := foo
> DYLIB_C_SOURCES := foo.c
> C_SOURCES := main.c
> CFLAGS_EXTRAS += -fPIC
>
> include $(LEVEL)/Makefile.rules
>
> The means a shared library needs to be created named "foo" and the sources
> for the shared library are foo.c.
>
> Most platforms include an automatic prefix to and libraries like:
> linux and freebsd is: "lib" + DYLIB_NAME + ".so"
> macosx is: "lib" + DYLIB_NAME + ".dylib"
>
> 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.
>
> So this setting just tries to set these things correctly for the current
> system.
>
> Because this test will launch the "a.out" and load the "libfoo.dylib"
> using the correct environment variable for you system.
>
> Greg
>
> > 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/bc91a701/attachment.html>