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