objdump, run on a relatively modern 64-bit linux system, complains as follows about one of our shared libs:
use of unsafe function-scope static in ‘lib64/libwhatever.so’.
What does that mean?
The man page doesn't mention 'unsafe' or 'function-scope' anywhere I can see.
"function-scope" doesn't appear in the binutils source tree, from what I can see. So maybe this comes from a vendor patch; in which case you ought to ask your vendor.
Related
I was having trouble with the linker for the embedded arm gcc compiler, and I found a tutorial somewhere online saying that I could fix my linker errors in arm-none-eabi-gcc by including the argument -specs=nosys.specs, which worked for me, and it was able to compile my code.
My chip is an ATSAM7SE256 microcontroller, which to my understanding is an arm7tdmi processor using the armv4t and thumb instruction sets, and I've been compiling my code using:
arm-none-eabi-gcc -march=armv4t -mtune=arm7tdmi -specs=nosys.specs -o <exe_name>.elf <input_files>
And the code compiles with no issue, but I have no idea if it's doing what I think it's doing.
What is the significance of a spec file? What other values can you set with -specs=, and in what situations would you want to? Is nosys.specs the value I want for a completely embedded arm microcontroller?
It is documented at: https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Overall-Options.html#Overall-Options
It is a file containing switches to override standard defaults for various build components such as the compiler, assembler and linker. For example it can be used to replace the default C library.
I have never seen it used; typically bare-metal embedded system builds explicitly specify --nostdlib then explicitly link the required library. It could be used for environment specific build environments to link other default code such as an RTOS I guess. Personally I'd rather make all that explicit on the command line that hiding it in a file somewhere.
Essentially it applies the switches specified in the file as if they were defaults, so can be used to define defaults for specific build and execution environments.
The format of the specs file is documented at https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Spec-Files.html#Spec-Files
Without seeing both the linker errors and the content of the nosys.specs file in this case it is difficult to say how or why it solved your linker problem. The alternative solution of course would be to apply whatever switches are in the specs file directly.
If you want to link a static library into an shared library or executable while keeping all the symbols visible (e.g. so you can dlopen it later to find them), a non-portable way to do this on Linux/BSD is to use the flag -Wl,--whole-archive. On macOS, the equivalent flag is -Wl,-force_load,<library>; on Windows it's apparently /WHOLEARCHIVE.
Is there a portable way to do this in CMake?
I know I can add linker flags with target_link_libraries. I can detect the OS. However, since the macOS version of this includes the library name in the same string as the flag (no spaces), I think this messes with CMake's usual handling of link targets and so on. The more compatible I try to make this, the more I have to bend over backwards to make it happen.
And this is without even getting into more unusual compilers like Intel, PGI, Cray, IBM, etc. Those may not be compilers that people commonly deal with, but in some domains it's basically unavoidable to need to deal with these.
Are there any better options?
flink.cmake will help you.
target_force_link_libraries(<target>
<PRIVATE|PUBLIC|INTERFACE> <item>...
[<PRIVATE|PUBLIC|INTERFACE> <item>...]...
)
Today I was in a discussion involving that libraries dont have an entry point.Generally the executable loads the libraries and the entry point is the main in the executable itself.
Are there execeptions wherein the libraries themselves can have an entry point ??
Update:
#sgr91 explained that DllMain is the entry point in Windows! What about linux ? Or is it just a feature of Windows ?
Yes, dynamic libraries do have entry-points.
It may be named differently (may or may not be exposed for usage), based on compiler and OS.
For Linux:
void __attribute__ ((constructor)) my_init(void);
void __attribute__ ((destructor)) my_fini(void);
The _init and _fini sections are now obsolete.
Read more
As mentioned in the title, this is a real beginner's question.
I'm realizing that after several years of CS courses and projects and such, I have never actually needed to export an executable that someone else could run without compiling the source manually (which is what most/all professors/TAs do, since they want to see your source code anyway).
So my question is basically this:
When I compile some basic C++ code (e.g. "Hello World" code), I always seem to need some sort of external DLLs to run it.
Visual Studio needs the .NET framework.
Cygwin needs Cygwin.dll.
MinGW needs libgcc_s_dw2-1.dll or something similar.
So how do I simply compile an executable such that I (or someone I give the file to) can just double-click it and have it run? I'm guessing there are some fancy command line flags I can use on g++ to statically link the DLLs; I have simply never needed to do this before.
As I said twice, this is a super beginner question, and yet I could not find (easily, anyway) an answer to this question, StackOverflow or anywhere else. Largely, I think, because the search terms are so commonly used in the descriptions for other problems.
Anyway, all help is appreciated.
EDIT:
I'm literally talking about a Hello World program. e.g.:
HelloWorld.cpp:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World!" << endl;
return 0;
}
Try g++ -static -static-libgcc
However, you should generally avoid static linking. Almost all the utilities on a usual Linux machine are dynamically linked: you can use file or ldd to know if an executable is statically linked. On my Debian/Sid system /usr/bin/ contains 7303 files, but only one is statically linked (it is /usr/bin/rar).
Using dynamic linking is better, because it uses less disk space, and most importantly because dynamic libraries are updated, and that profit to all the executables dynamically linking them.
If you care about dependencies, use your package manager (or distribute your program as a package).
If you already got the static lib you need to link in, (.lib or .a), just put them together with the object files when you linking your application, like
g++ foo.o libfoo.a -o foo
I think your real problem is how to locate which static libs are required by your application and how to get them, maybe you should post your code here and let us know what library you need to link in.
Here is how:
simply put, you specify to link all the standard stuff into your executable.
g++ -o c:\prog.exe c:\HelloWorld.cpp -static-libgcc -static-libstdc++
hope it helps.
Is it possible to extract a binary, to get the code that is behind the binary? With Class-dump you can see the implementation addresses, but is it possible to also see the code thats IN the implementation addresses? Is there ANY way to do it?
All your code compiles to single instructions, placed in the text section of your executable. The compiler is responsible for translating your higher level language to the processor specific instructions, which are simpler. Reverting this process would be nearly impossible, unless the code is quite simple. Some problems are ambiguity of statements, and the overall readability: local variables, for instance, will be nothing but an offset address.
If you want to read the disassembled code (the instructions of which the higher level code was compiled to) use this command in an executable:
otool -tV file
You can decompile (more accurately, disassemble) a binary and get it's assembly, but there is no way to get back the original Objective-C.
My curiosity begs me to ask why you want to do this!?
otx http://otx.osxninja.com/ is a good tool for symbolicating the otool based disassembly
It will handle both x86_64 and i386 disassembly.
and
Mach-O-Scope https://github.com/smorr/Mach-O-Scope is a a tool built on top of otx to dump it all into a sqlite3 database for browsing and annotating.
It won't give you the original source -- but it will get you pretty close providing you with the messages that are being sent around in methods.