> On Dec 2, 2014, at 4:37 PM, Zachary Turner <[email protected]> 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 <[email protected]> wrote: > Looks like you will need to modify the make rules in: > > https://[email protected]/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 <[email protected]> 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 <[email protected]> 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 > > > > > _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
