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/Users/fi! lcab! > > > > > > > > > /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 > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
