Sending source/Interpreter/Makefile Transmitting file data . Committed revision 157621.
Thanks, Filipe On Saturday, May 26, 2012 at 2:22 AM, Filipe Cabecinhas wrote: > And here is the patch. > > Filipe > > > On Friday, May 25, 2012 at 7:21 PM, Filipe Cabecinhas wrote: > > > Hi all, > > > > Here is the update patch with both patches + some tweaks. Please check it > > on Linux and fBSD too, if you can. > > > > Regards, > > > > Filipe > > > > > > On Wednesday, May 23, 2012 at 5:58 PM, Greg Clayton wrote: > > > > > > > > On May 23, 2012, at 3:48 AM, Filipe Cabecinhas wrote: > > > > > > > Thanks for the info. > > > > > > > > So, the problem is lldb-platform using stuff from lldb_private. We > > > > should change that. > > > > > > This is how lldb-platform is designed (for now) so we really can't change > > > this yet. lldb-platform is taking advantage of many innards of LLDB such > > > as the host layer stuff and mainly right now the GDB remote > > > communications class. Eventually I would like to get the lldb-platform to > > > be libssl based, but for now we are using the GDB remote communications > > > as a way to get a connection to a remote platform. The idea behing the > > > platform is to have a binary that can take advantage of the work we have > > > already done in the host layer (list and launch processes, run shell > > > command etc) and vend that through some communication channel. It is true > > > that eventually we can make the lldb-platform use the public API, but we > > > aren't there yet. > > > > > > > > > > Another problem is: why does this bug only appear in Makefile builds. > > > > The Mac OS X framework also uses that file for exported symbols. > > > > But lldb-platform doesn't link against the Framework. It only links > > > > against liblldb-core.dylib (and some system frameworks, of course). If > > > > I make it link against LLDB.framework instead, I get the same errors > > > > (as expected). > > > > > > > > > > > > > > > > > > > > > > > > It actually shouldn't link against "liblldb-core.dylib", it should link > > > the static libraries. This should clear up the linking issues you are > > > running into. > > > > > > > > > > > There are two options: Make lldb-platform link against the static > > > > library everywhere (at least make it do the same for every build > > > > system), or make it link against the dynamic library/framework > > > > everywhere. > > > > > > Yes, it should currently link against the the static libraries (.a files). > > > > > > > > > > > Regards, > > > > > > > > Filipe > > > > > > > > > > > > On Wednesday, May 23, 2012 at 4:13 AM, Charles Davis wrote: > > > > > > > > > > > > > > On May 22, 2012, at 6:10 PM, Filipe Cabecinhas wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I was fixing lldb's Makefile build system, and updating it with > > > > > > Dragos' LLVMLibsOptions and Charles' python packaging (with printf > > > > > > instead of echo -n) patches. > > > > > > > > > > > > But I'm having some weird problems. Everything builds fine with > > > > > > FreeBSD (haven't tested the Python part yet), but on Mac OS X Lion > > > > > > (the latest), I get this: > > > > > > > > > > > > llvm[4]: Linking Debug+Asserts executable lldb-platform > > > > > > clang++ -I/Users/filcab/dev/svn-llvm/build/include > > > > > > -I/Users/filcab/dev/svn-llvm/build/tools/lldb/tools/lldb-platform > > > > > > -I/Users/filcab/dev/svn-llvm/include > > > > > > -I/Users/filcab/dev/svn-llvm/tools/lldb/tools/lldb-platform > > > > > > -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS > > > > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > > > > > > -I/Users/filcab/dev/svn-llvm/tools/lldb/tools/lldb-platform/../../include > > > > > > > > > > > > -I/Users/filcab/dev/svn-llvm/build/tools/lldb/tools/lldb-platform/../../include > > > > > > -I/Users/filcab/dev/svn-llvm/tools/clang/include > > > > > > -I/Users/filcab/dev/svn-llvm/build/tools/clang/include > > > > > > -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 > > > > > > > > > > > > -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 > > > > > > > > > > > > -I/Users/filcab/dev/svn-llvm/tools/lldb/tools/lldb-platform/../../source > > > > > > > > > > > > -I/Users/filcab/dev/svn-llvm/tools/lldb/tools/lldb-platform/../../source/Utility > > > > > > > > > > > > -I/Users/filcab/dev/svn-llvm/tools/lldb/tools/lldb-platform/../../source/Plugins/Process/Utility > > > > > > -I/User! s/filcab! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /dev/svn- > > > > llvm > > > > > > /tools/lldb/tools/lldb-platform/../../source/Plugins/Process/POSIX > > > > > > -F/System/Library/Frameworks -F/System/Library/PrivateFrameworks -g > > > > > > -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common > > > > > > -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -g -Wl,-rpath > > > > > > -Wl,@executable_path/../lib > > > > > > -L/Users/filcab/dev/svn-llvm/build/Debug+Asserts/lib > > > > > > -L/Users/filcab/dev/svn-llvm/build/Debug+Asserts/lib -m64 -pedantic > > > > > > -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings > > > > > > -Wno-unknown-pragmas -Wno-sign-compare -Wno-sign-compare > > > > > > -Wno-unused-function -Wcovered-switch-default -o > > > > > > /Users/filcab/dev/svn-llvm/build/Debug+Asserts/bin/lldb-platform > > > > > > /Users/filcab/dev/svn-llvm/build/tools/lldb/tools/lldb-platform/Debug+Asserts/lldb-platform.o > > > > > > \ > > > > > > -llldb -llldbUtility -Wl,-rpath,@loader_path/../lib/ -lpthread -lm > > > > > > > > > > > > > > > > > > Undefined symbols for architecture x86_64: > > > > > > "__ZN12lldb_private4ArgsC1EPKc", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private5ErrorC1Ev", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private8Debugger10InitializeEv", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private10StreamFileC1EP7__sFILEb", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private4Args14AppendArgumentEPKcc", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZNK12lldb_private4Args16GetArgumentCountEv", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZNK12lldb_private4Args22GetConstArgumentVectorEv", referenced > > > > > > from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN19ProcessGDBRemoteLog9EnableLogERNSt3tr110shared_ptrIN12lldb_private6StreamEEEjPPKcPS3_", > > > > > > referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN28GDBRemoteCommunicationServerC1Eb", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private24ConnectionFileDescriptorC1Ev", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private13Communication13SetConnectionEPNS_10ConnectionE", > > > > > > referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZNK12lldb_private13Communication11IsConnectedEv", referenced > > > > > > from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN28GDBRemoteCommunicationServer19HandshakeWithClientEPN12lldb_private5ErrorE", > > > > > > referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN28GDBRemoteCommunicationServer24GetPacketAndSendResponseEjRN12lldb_private5ErrorERbS3_", > > > > > > referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZNK12lldb_private5Error4FailEv", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZNK12lldb_private5Error9AsCStringEPKc", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private8Debugger9TerminateEv", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN28GDBRemoteCommunicationServerD1Ev", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private5ErrorD1Ev", referenced from: > > > > > > _main in lldb-platform.o > > > > > > "__ZN12lldb_private4ArgsD1Ev", referenced from: > > > > > > _main in lldb-platform.o > > > > > > ld: symbol(s) not found for architecture x86_64 > > > > > > clang-3: error: linker command failed with exit code 1 (use -v to > > > > > > see invocation) > > > > > > make[4]: *** > > > > > > [/Users/filcab/dev/svn-llvm/build/Debug+Asserts/bin/lldb-platform] > > > > > > Error 1 > > > > > > > > > > > > The problem is that every symbol is there, but marked as local: > > > > > > $ nm Debug+Asserts/lib/liblldb.dylib| grep > > > > > > __ZNK12lldb_private4Args22GetConstArgumentVectorEv > > > > > > 0000000000275230 t > > > > > > __ZNK12lldb_private4Args22GetConstArgumentVectorEv > > > > > > $ nm Debug+Asserts/lib/liblldb.dylib| grep > > > > > > __ZN28GDBRemoteCommunicationServerC1Eb > > > > > > 00000000003beca0 t __ZN28GDBRemoteCommunicationServerC1Eb > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yeah, I had to change the liblldb Makefile so everything gets > > > > > exported: > > > > > > > > > > -EXPORTED_SYMBOL_FILE = > > > > > $(PROJ_SRC_DIR)/../resources/lldb-framework-exports > > > > > +#EXPORTED_SYMBOL_FILE = > > > > > $(PROJ_SRC_DIR)/../resources/lldb-framework-exports > > > > > > > > > > That should fix both errors you're seeing. > > > > > > > > > > By the way, here's an updated version of my libInterpreter Makefile > > > > > patch--new and improved, now with update to the test suite Makefile. > > > > > It also avoids the need for printf(1) entirely--it just uses one > > > > > echo(1) statement for the module list in the __init__.py files. > > > > > > > > > > Chip > > > > > > > > > > > > > > > Attachments: > > > > > - python-packaging.patch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lldb-dev mailing list > > > > [email protected] (mailto:[email protected]) > > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > > Attachments: > - lldb-makefiles.patch > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
