I have an executable that makes use of /usr/lib/libcrypto.0.9.8.dylib. I've (more or less) figured out some breakpoints within that library that I'd like to understand better.
However, I do not remember if this is the stock openssl on the system, or if I later installed it (don't think so, pretty sure that homebrew would have put it elsewhere).
This is for macOS Mojave (10.14). If the debug symbols have been stripped in libcrypto, I'm not sure I even know how to check that (nm?). I have, however, downloaded and extracted the source (matching the version).
Is there any way to configure lldb such that it can show me the source code instead of assembly language? If the debugging symbols have been stripped (without even checking, I'd assume so) can you even do this?
I'm trying to do my own research for this, but I'm not even sure I know what keywords to search with yet.
The tools on Darwin don't store debug information in the binaries, but rather in a separate standalone bundle (a dSYM). So if you don't have a dSYM for your libcrypto then you don't have debug information for it, and there's no way to reconstruct the code->source map.
Some distributions have debug packages as well as release ones that include the dSYM's. lldb matches dSYM to binary using a common UUID computed by the linker. You can print the UUID with the command dwarfdump --uuid <PATH TO BINARY> and then see if wherever you got the library from kept that dSYM.
But if you can't find the dSYM, you aren't going to be able to do any source level debugging.
Related
Related:
How to compile srlua?
How do I Make an executable Lua script using srlua?
The first link is the exact question I am asking here. However, the sole answer is unsatisfactory as it assumes multiple things, namely that the OP is already using Cmake (a fact disproved by the OP's comment on the answer). The second link seems to already be most of the way through a tutorial, and while a link to precompiled binaries for both srlua.exe and srglue.exe are provided, the link no longer contains binaries but instead the source.
I have found several other threads on various websites all asking the same thing, but all of them either assume that you essentially already know how, or explain nothing (many have potentially helpful links, but they are old and no longer work).
I have already tried to compile srlua, and got a srglue.exe, but when I tried srlua.c I ended up with a list of undefined references (such as "lua_type" or "lua_getfield").
lua_getfield, lua_type, lua_settop, lua_getfield, lua_type, lua_settop, lua_pushstring, lua_pushinteger, lua_call, lua_pushfstring, lua_load, lua_tolstring, lua_tointeger, lua_touserdata, luaL_openlibs, lua_createtable, lua_pushstring, lua_rawseti, lua_setfield, luaL_checkstack, lua_pushstring, lua_call, lua_tolstring, luaL_callmeta, lua_type, lua_type, lua_typename, lua_pushfstring, luaL_newstate, lua_pushcclosure, lua_pushcclosure, lua_pushinteger, lua_pushlightuserdata, lua_pcall, lua_tolstring, lua_close
My question is this:
How does one use a C compiler (I know the basics of gcc) to compile srlua specifically? Or, if anyone has a functioning link to either precompiled binaries or a tool to compile the binaries, could they share it?
Important: I am on Windows. Thus, I cannot just use make. I must actually compile the .c files to .exe files. I am asking how. If you simply provide links to threads with the aforementioned problems, you are not helping. If you give an answer that assumes in-depth prior knowledge of a particular tool that does not have good documentation, you are not being helpful. If you tell me tools to use, but not the specific procedure for compiling srlua, you are not being helpful. If there is a better place for this, tell me and I can move it there.
I don't know any Windows pre-compiled binaries for srLua.
To compile srLua, you should first install the Mingw compiler to use GCC as a C compiler : you can install TDM-GCC (https://jmeubank.github.io/tdm-gcc) or http://winlibs.com.
You can then open a Console prompt. Enter the "gcc" command to be sure that the compiler is working (and that the PATH is correctly set).
Then go to the directory you extracted the srLua source files and type the command :
mingw32-make
Cross your fingers and it should compile everything :)
When linking, you should include the Lua libraries with the -l Switch : -llua54 for Lua 5.4 library for examples.
I found this already compiled release on webarchive, it's kinda old but works:
https://web.archive.org/web/20130721014948/http://www.soongsoft.com/lhf/lua/5.1/srlua.tgz
This is the problem:
(On Linux Slackware64) I compiled Inkscape (0.92.3) and found that exporting to PNG doesn't work. An indication on the terminal tells me:
libpng warning: Application built with libpng-1.6.16 but running with 1.5.13
First reaction was to list the linked libraries using ldd. Indeed, both libpng-1.6.16 and libpng-1.5.13 are listed as necessary.
So, I suspected that some of the other libraries was requiring libpng-1.5.13. I made a small Python program which takes all the libraries (except the libpngs) and applies ldd to each of them. None of them listed libpng15. What now? I suspect that if any of the secondary libraries needed libpng15, it would be listed here, but, just in case I made the search recursive. No luck.
So it was, apparently, inkscape itself requesting the old version. A simple search in all files in the search tree only showed the string 'png15' in the viewer and actual inkscape executable.
There are probably older programs of mine still linked with png15, so I probably want to keep that version around.
Most, if not all references on the net mentioning this error (or similar) refer to programs with very old pnglibs (1.2.4x) trying to use a newer version, but here it's the other way around.
libpng-config --version reports 1.6.16
Any suggestion how to identify the source of this problem? Particularly why inkscape included the old libpng?
I would like to deploy a .dylib on OSX, which has been created with Delphi. This .dylib should be loadable by third-party applications.
This is going to seem like a duplicate question, but after plenty of searching, I can't find an answer for it. It's the same issue as this: https://forums.embarcadero.com/thread.jspa?messageID=592417
The problem is that the .dylib requires libcgunwind.1.0.dylib, but that it cannot find it when being run from a third-party application. As a test, I tried copying libcgunwind.1.0.dylib into usr/lib, and that worked. When OSX cannot locate the .dylib, it will always search in usr/lib. Unfortunately, I do not want to do this as a final solution, because it would require elevated permissions, and seems like a heavy handed way of dealing with a simple problem.
Inspecting a bit closer, I used otool to inspect my .dylib, and it gave me the following path: #rpath/libcgunwind.1.0.dylib.
The trouble is, there's no accounting for what paths will be listed in #rpath, when your .dylib is being run by a third-party application. For this to work, the application would always have to provide an absolute path to libcgunwind.1.0.dylib.
The obvious solution is to use install_name_tool to replace #rpath with #loader_path. If my logic is correct, this should cause my .dylib to always find libcgunwind.1.0.dylib, as long as they are in the same folder. This makes sense, as the .dylib ought to be in charge of finding its own dependencies.
So, I tried the following command line:
install_name_tool -change #rpath/libcgunwind.1.0.dylib #loader_path/libcgunwind.1.0.dylib libTest.dylib
and received this message:
install_name_tool: file not in an order that can be processed (local relocation entries out of place): libTest.dylib
I did some searching around for this error message, and I haven't been able to find any information on it. I have to assume that install_name_tool is expecting some specific conventions found in a gcc or llvm built .dylib, and that Delphi's compiler is not providing those conventions.
I did some digging around in Delphi's compiler dccosx, and checked the command-line arguments Delphi is sending to it, but I can't find any useful options. This way of using libcgunwind.1.0.dylib, seems to be implicit to the compiler, and not something I can adjust.
I'm not suggesting that this is the right way to tackle the issue, these are just the latest things that I've tried. If you can come up with a different way of working around the problem, please share your ideas!
The install_name_tool seems to require that certain parts of the dylib are in a certain order like "local relocation entries" then "symbol table", "local symbols", ... The error message means that this order is not as expected.
My suggestion is that you try to patch the dylib file. I do that all the time with OSX executables because I need to tell them which dylib versions they are compatible with. This fixes a couple of bugs in a Delphi OSX application. A dylib has a very similar structure as the executable. My experience is that patching these files is not as complicated as it sounds.
You can find the description of the file structure here:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
The LC_LOAD_DYLIB section is what you'll need to look at. You should be able to replace the dylib names with something longer as this section usually has some extra padding.
I have XCode 5 installed, I can use command-line lldb just fine. Now I want to create my own application that will link with LLDB C++ interface. I tried to search through the XCode package and found no .a archives, no headers. Does this mean I need to build LLDB locally (and go through the signing process)?
it is indeed correct that there are no header files included in the LLDB.framework that comes with Xcode
With that said, you have two possible avenues:
build LLDB from source, as you said, and then use the built ToT to write your app
obtain the headers from our open source repository and put them in the magical location in the Xcode-provided LLDB.framework and that should enable you to link successfully against whatever LLDB you have.
The incantation should be to make an Headers folder in LLDB.framework/Versions/A and copy all the PUBLIC headers from our sources into there (you want LLDB.h, all the SB*.h files and lldb-defines,enumerations,forward,public,types,versioning.h) - then go into LLDB.framework and make a symlink named Headers to Versions/Current/Headers
Just an FYI - the public API (SB*.h) is all that is pretty much supported and guaranteed to be relatively stable. If you start trying to use the private layer (lldb_private::*), you are going to be on your own and breakages might be fairly frequent as the internals of the debugger evolve
I understand it is somehow making a connection so that a compiler when envokes connects a source code to whatever libraries that it needs to.
But what is going on a more technical level, or better put what do I need to know in order to confidentally compile code.
I'm working with C++ and MinGW, and have started to look into build files and stuff for Sublime Text 2 (Have learned mostly under unix, or Java + eclipse so far). But what I don't understand what is adding a compiler to your path do for you?
Do I need to add it for every folder I want to compile from? Or is it system wide? I'm really learning this stuff for the first time, we we're never showed how to set up development environments or even deploy code on other systems.
You probably mean include paths and library paths in the compiler:
include paths: where the compiler will look for headers; and
library paths: where the linker, invoked by the compiler, will look for binary libraries to finish building your project.
If that is the case, look here for a gentle explanation.
Basically, what is happening is that the compiler looks in certain places for symbols defined by the operating system and other libraries installed system-wide.
In addition to those paths, you need to tell the compiler where to find the symbols defined in your own project.
You may also mean something related to installing the compiler itself or configuring the editor to use it.
In that case, what is happening is that you need to tell the build system where to find the executable for the compiler.
Basically, what is probably happening is that your editor wants to know where the compiler is so that it can provide real time feedback on your code. Adding the compiler to the system path will usually, but not always, solve your problem.
In more detail:
A C++ build is a rather complex tool chain, involving determining dependencies, preprocessing, compiling, and linking. There are tools that automate that tool chain, and those tools are in turn wrapped into the functionality of modern IDEs like Eclipse, Visual C++, or Sublime Text 2. You many need to tell your editor where to find the tools it uses to provide you with those services.