I know that FreePascal apps for Linux are statically linked. I imagine that there are some low-level APIs required. Is this just GTK for GUI applications? I assume a command-line app wouldn't have the same dependencies.
Where can I find a way to determine which LCL classes require which underlying APIs?
Edit:
Vitaly wanted to know what I found with his answer.
With a small console app:
ldd confirmed that it was a statically linked executable.
strace was more interesting. A console-only application showed no open files. I guess it's totally self contained.
With a simple GUI application, ldd showed some dynamic linking, and strace's output showed many "open"s.
It'll still take a little more research before I'm comfortable with this.
Since they are statically linked, exactly what kind of dependencies could they have?..
However you can try to work it out with a several methods...
ldd <executable> (just to be sure that your binary is not dynamically linked)
strace <executable> > log.file 2&>1 && cat log.file | grep open
Where can I find a way to determine which LCL classes require which underlying APIs?
From my point of view, this purpose requires some hard work. I'd advice to try systemtap for the one.
Related
I think a major design flaw in Linux is the shared object hell when it comes to distributing programs in binary instead of source code form.
Here is my specific problem: I want to publish a Linux program in ELF binary form that should run on as many distributions as possible so my mandatory dependencies are as low as it gets: The only libraries required under any circumstances are libpthread, libX11, librt and libm (and glibc of course). I'm linking dynamically against these libraries when I build my program using gcc.
Optionally, however, my program should also support ALSA (sound interface), the Xcursor, Xfixes, and Xxf86vm extensions as well as GTK. But these should only be used if they are available on the user's system, otherwise my program should still run but with limited functionality. For example, if GTK isn't there, my program will fall back to terminal mode. Because my program should still be able to run without ALSA, Xcursor, Xfixes, etc. I cannot link dynamically against these libraries because then the program won't start at all if one of the libraries isn't there.
So I need to manually check if the libraries are present and then open them one by one using dlopen() and import the necessary function symbols using dlsym(). This, however, leads to all kinds of problems:
1) Library naming conventions:
Shared objects often aren't simply called "libXcursor.so" but have some kind of version extension like "libXcursor.so.1" or even really funny things like "libXcursor.so.0.2000". These extensions seem to differ from system to system. So which one should I choose when calling dlopen()? Using a hardcoded name here seems like a very bad idea because the names differ from system to system. So the only workaround that comes to my mind is to scan the whole library path and look for filenames starting with a "libXcursor.so" prefix and then do some custom version matching. But how do I know that they are really compatible?
2) Library search paths: Where should I look for the *.so files after all? This is also different from system to system. There are some default paths like /usr/lib and /lib but *.so files could also be in lots of other paths. So I'd have to open /etc/ld.so.conf and parse this to find out all library search paths. That's not a trivial thing to do because /etc/ld.so.conf files can also use some kind of include directive which means that I have to parse even more .conf files, do some checks against possible infinite loops caused by circular include directives etc. Is there really no easier way to find out the search paths for *.so?
So, my actual question is this: Isn't there a more convenient, less hackish way of achieving what I want to do? Is it really so complicated to create a Linux program that has some optional dependencies like ALSA, GTK, libXcursor... but should also work without it! Is there some kind of standard for doing what I want to do? Or am I doomed to do it the hackish way?
Thanks for your comments/solutions!
I think a major design flaw in Linux is the shared object hell when it comes to distributing programs in binary instead of source code form.
This isn't a design flaw as far as creators of the system are concerned; it's an advantage -- it encourages you to distribute programs in source form. Oh, you wanted to sell your software? Sorry, that's not the use case Linux is optimized for.
Library naming conventions: Shared objects often aren't simply called "libXcursor.so" but have some kind of version extension like "libXcursor.so.1" or even really funny things like "libXcursor.so.0.2000".
Yes, this is called external library versioning. Read about it here. As should be clear from that description, if you compiled your binaries using headers on a system that would normally give you libXcursor.so.1 as a runtime reference, then the only shared library you are compatible with is libXcursor.so.1, and trying to dlopen libXcursor.so.0.2000 will lead to unpredictable crashes.
Any system that provides libXcursor.so but not libXcursor.so.1 is either a broken installation, or is also incompatible with your binaries.
Library search paths: Where should I look for the *.so files after all?
You shouldn't be trying to dlopen any of these libraries using their full path. Just call dlopen("libXcursor.so.1", RTLD_GLOBAL);, and the runtime loader will search for the library in system-appropriate locations.
Under Windows I installed MinGW and Eclipse, and created a new C++ project with the inspiring name of foo, using the MinGW GCC toolchain, and this compiles, runs and even debugs. Wonderful.
Still under Windows, I installed Cygwin, an epic undertaking that stressed my internet connection. Eventually I specified Cygwin GCC toolchain and a projectname of bar. This compiles and runs but can't do step through debugging (claims it can't find source).
Under Linux, mint13 specifically, I installed the all-singing all-dancing C++ edition of Eclipse with all the trimmings and created a new C++ project, with the even more inspiring name of baz and the Linux GCC toolchain selected. Eclipse complains that it cannot find iostream.
I am rather confused by this. If I launch a terminal window and run g++ it is found, so clearly I have at least some of the GNU C++ stuff. I don't know what is missing. Linux is a new world for me. Can anyone offer guidance?
For the record, the generated code is in a file called foo.cpp (or bar.cpp according to project name) and looks like this:
#include <iostream>
using namespace std;
int main() {
cout << "Hello World" << endl; // prints Hello World
return 0;
}
#bmargulies - I know your comment was tongue in cheek but I wouldn't use emacs in a pink fit. I'd set up SAMBA and use Textpad on a Windows workstation because I have enough to learn without unnecessarily learning to use a new text editor. The reason I chose Eclipse was a vain hope that it might provide a working baseline with an integrated debugger from which to explore the brave new world of C++ on Linux. Combined with MinGW it did provide that on Windows.
I know the big problem here is not the tools, it is my ignorance and a set of expectations from a different world. This is compounded by a lack of experience with C++ - my sole experience with C++ was using TurboC fifteen years ago.
A source of great confusion is the mechanism used to resolve library references.
A lot of projects seem to use make, which as far as I can tell is a sort of script file for compiling and linking a project or set of projects. Make seems to come in a variety of flavours and there also seem to be alternatives that use makefile as well as alternatives that don't.
[expletive] what a mess.
#Basile - I am not wedded to the use of Eclipse, and I am well aware of the benefits of scripts over point and click use of IDE configuration (not least among which is that you can source-control the build process). I thank you for your reading list. Perhaps this is a silly (or premature) question but I have to ask: without an IDE like Eclipse that integrates an editor with a build tool, is it possible to do step-through debugging?
#bmargulies - I agree with you that there's probably something wrong with the toolchain definition but I lack the background and experience to conduct a meaningful investigation of that. As mentioned above, I had varying levels of success with different toolchains under Windows, so it is reasonable to conclude that the toolchain is a significant factor in the problem. Alas, I can't choose a MinGW toolchain under Linux.
Following Norm's advice I was able to compile foo.cpp from a command line. The hello world program executes with the desired behaviour, but I still don't know how g++ knew how to resolve iostream when the fancy IDE tool didn't.
Added a few more lines of code to foo and compiled it, to try out gdb. It works! Whoever would have imagined you could do step-through debugging with a teminal window! It's a bit clumsy though.
While Basile is clearly correct that a fancy IDE is not necessary, that's a bit like saying that I don't need my motorcycle because I can walk. I'll have a look at the other IDEs mentioned, but I suspect they will all make use of the same toolchains and therefore all be similarly afflicted by whatever I have misconfigured.
Basile, forgive me for moving the goalposts. My original goal was indeed "compile and run hello.cpp" but gdb was inevitably the next step. It works, and if this were the early 80s using a teletype at uni I would probably be pretty happy right now. But it's not the early eighties and I've spent the last decade with syntax-colouring, autocompletion, variable sniffing edit-and-continue debugging so (ungrateful sod that I am) now I want, well, everything!
I've used eclipse c/C++ version before and had a lot of the same problems. For me, eclipse was very difficult to work with. I would recommend using the command line to compile c/c++ programs to start with. Its easier and important to understand how executable are created, in my opinion.
g++ -Wall -g Hello.cpp -o Hello
will produce an executable Hello. -Wall is a option that gives you more warnings when you are compiling your programs. Some warnings will crash your program if you don't fix them so its nice to see them up front. -g gives you the debugging symbols so that gdb will be able to step through the program step by step.
When you do get into gdb by using gdb Hello you can check out this gdb cheatsheet.
Once you start writing programs with more than one source file you're going to need to understand the two main steps in compilation. The first step turns each individual source file into an object file. The next step links all the object files together to make an executable. This link might explain compiling and linking, obviously wikipedia is also a good source for that info.
You don't need a fancy IDE like Eclipse. The usual way of developing under Linux is to use several tools.
Use an editor like emacs or gedit to edit your helloworld.cpp file. Type emacs or gedit in your terminal to start the editor (possibly followed by helloworld.cpp i.e. the name of the edited file[s]).
Then, compile with the following command
g++ -Wall -g helloworld.cpp -o helloworld
that you type in your terminal. Improve your code till no warning is given. You might add -O after -g above if you want GCC to optimize (and -O2 or -O3 to optimize even more). You should ask GCC to optimize if you want to benchmark or release your binary executable program. Notice that g++ knows how to link the standard C++ library (libstdc++.so), and the headers are located in a standard location known to g++ (you could add a -v argument to g++ to make it show what is happenning). You'll need more arguments if you want to use additional libraries.
the order of arguments to g++ is important, particularly for -I options (include directories) and -l (libraries).
If you want to debug your program (avoid asking optimizations to GCC), type
gdb helloworld
which will run the debugger. Learn more about gdb (of course you can do step by step with gdb; you'll use the next, step, break, backtrace commands of gdb at first, and others -e.g. watch is very useful sometimes.)
If you want to run your program without a debugger, just type
./helloworld
Later, you'll want to develop a program in several compilation units. Learn to use a bulder like make for that. There are other builder programs, like omake and many others.
Read more about GCC (providing g++), Gnu Make, GDB (the gnu debugger), Emacs, GIT version control
I have configured my emacs to run make inside it by pressing the F12 key. You can compile under emacs if you want to.
For graphical user interface applications coded in C++, learn to use Qt.
PS. Linux is much more command line oriented that other systems. Believe us, this has incredible strengths. But it is a different way of working that on other systems, such as those sold by Microsoft.
PS. If you are fond of IDE, you could consider geany, anjuta, kate. However, few free software - coded in C or C++ - in a typical Linux distribution (Debian, Ubuntu, Fedora, ...) are built using these (or with Eclipse, which on Linux is often related to Java development). IMHO, this is significant.
I'm using Eclipse, and when I debug, the values of the list variables are unreadable and cryptic. How can I see those values?
I'm on Linux.
GDB 7 has support for python scripting which can be used to write pretty printers. For STL, the pretty printers need to understand the details of the implementation, so the pretty printers definitions must be supplied as part the standard library implementation.
For libstdc++, you can get a copy of the pretty printers from here, though you probably want to track down the specific version of that file that matches your particular libstdc++ version.
You will need to do some work to educate your copy of GDB about this file, probably via the gdb 'source' command, but once you have convinced GDB to load it you should be able to pretty print many STL data structures, std::list included.
I have a portal in my university LAN where people can upload code to programming puzzles in C/C++. I would like to make the portal secure so that people cannot make system calls via their submitted code. There might be several workarounds but I'd like to know if I could do it simply by setting some clever gcc flags. libc by default seems to include <unistd.h>, which appears to be the basic file where system calls are declared. Is there a way I could tell gcc/g++ to 'ignore' this file at compile time so that none of the functions declared in unistd.h can be accessed?
Some particular reason why chroot("/var/jail/empty"); setuid(65534); isn't good enough (assuming 65534 has sensible limits)?
Restricting access to the header file won't prevent you from accessing libc functions: they're still available if you link against libc - you just won't have the prototypes (and macros) to hand; but you can replicate them yourself.
And not linking against libc won't help either: system calls could be made directly via inline assembler (or even tricks involving jumping into data).
I don't think this is a good approach in general. Running the uploaded code in a completely self-contained virtual sandbox (via QEMU or something like that, perhaps) would probably be a better way to go.
-D can overwrite individual function names. For example:
gcc file.c -Dchown -Dchdir
Or you can set the include guard yourself:
gcc file.c -D_UNISTD_H
However their effects can be easily reverted with #undefs by intelligent submitters :)
I'm building a .so plugin and would like to profile it using gprof. At the moment, I don't have the ability to rebuild (with the -pg option) the executable that links to it. Is it possible to use gprof to profile just this .so file once it's loaded up and linked to?
It's not possible with gprof (in my experience, gprof basically doesn't work unless you can statically link everything including libc, and the libc people really don't want you to do that these days) but you should be able to do this with kcachegrind. It'll give you details on the whole program, but with no symbols for the part you don't have source for, and you just ignore that part. Bonus: no need to recompile.
As Zack said, gprof won't do that.
But even if it did, you could be disappointed, because gprof only finds certain kinds of problems. If you find and fix those problems, you are left with performance being limited by the problems it didn't find.
Here's a list of issues, not just with gprof, but with many profilers.
Give Zoom a try.