Makefile build

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

Linking liblldb.dylib also had this error message, btw. I don't know how bad it is. There's not much info available:
ld: warning: cannot export hidden symbol __ZN4lldb7SBValue6get_spEv from /Users/filcab/dev/svn-llvm/build/Debug+Asserts/lib/liblldbInterpreter.a(ScriptInterpreterPython.o)

Any clues?

  Filipe

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

python-packaging.patch (9.2 KB)

Thanks for the info.

So, the problem is lldb-platform using stuff from lldb_private. We should change that.

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).

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.

Regards,

  Filipe

> 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

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).

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

> 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
>
>
>
> >
> >
> > > 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!

And here is the patch.

  Filipe

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

>
>
> > 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
> >
> >
> >
> > >
> > >
> > > > 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!

lldb-makefiles.patch (13.6 KB)

Sending source/Interpreter/Makefile
Transmitting file data .
Committed revision 157621.

Thanks,

  Filipe

And here is the patch.

Filipe

> 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
>
>
>
> >
> >
> > > 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
> > >
> > >
> > >
> > > >
> > > >
> > > > > 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!