[lldb-dev] Makefile build

Filipe Cabecinhas filcab at gmail.com
Tue May 29 07:09:51 PDT 2012 

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, at 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, at 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
> > > > lldb-dev at cs.uiuc.edu (mailto:lldb-dev at cs.uiuc.edu)
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > > 
> > 
> 
> 
> 
> Attachments: 
> - lldb-makefiles.patch
>

More information about the lldb-dev mailing list