linker interview questions
Top linker frequently asked interview questions
I can't find anywhere what the -all_load flag do when compiling Objective-C code.
I have some issues uploading binaries to Apple, the they say it's because I didn't use this flag, but my code compiles even without it.
Can some one help me with that?
Thanks
Source: (StackOverflow)
I just ran across the following error (and found the solution online, but it's not present in Stack Overflow):
(.gnu.linkonce.[stuff]): undefined
reference to [method] [object
file]:(.gnu.linkonce.[stuff]):
undefined reference to `typeinfo for
[classname]'
Why might one get one of these "undefined reference to typeinfo" linker errors?
(Bonus points if you can explain what's going on behind the scenes.)
Source: (StackOverflow)
I often hear the terms 'statically linked' and 'dynamically linked', often in reference to code written in C, C++ or C#, but I don't know much of anything about either. What are they, what exactly are they talking about, and what are they linking?
Source: (StackOverflow)
I've created a new C++ project in Visual Studio 2008. No code has been written yet; Only project settings have been changed.
When I compile the project, I receive the following fatal error:
fatal error LNK1104: cannot open file 'C:\Program.obj'
Source: (StackOverflow)
Many people here are probably familiar with one of Joel Spolsky most popular blog posts, Please Sir, May I Have a Linker, where he cries out for a way to remove dependencies on the .NET framework so a stand-alone application can be developed and sold.
Jason Zander of the Visual Studio development team, at the time, replied with his views on the topic, arguing that the topic is somewhat moot - the ability to fix security problems in the runtime (among other points) was their chief concern. Overall, the small overhead was worth it.
Fast forward to 2009. There's a few groups out there now claiming to have C# linkers. (Jason Zander even said himself that it wouldn't take much to implement one.) Instead of the cute, dozen-so meg download of .NET 1.0, we now have a massive 200-300 mb cross-platform complete .NET 3.5 installer that contains versions of .NET for x86, x64, and ia64. Microsoft's suggestions to decrease the runtime size include:
- Unpack the redistributable, remove the target platforms you don't want, and put it back together
- Use the web bootstrapper that only downloads the libraries for your platform
- Use the Client Profile installer (new as of late 2008) which has limited libraries and only works for x86
To make matters worse, as I understand it (please correct me if I'm wrong) the client profile don't even register with windows as having .NET 3.5 installed. This means if multiple .NET 3.5 client applications are installed on the computer, none will see each other and the runtime will be re-installed again and again!
I really don't know what Microsoft is thinking here. Even assuming the worst case install will be for one target platform (eg, x64) and only those libraries need to be included, you're still looking at upwards of 60 mb overhead on your app. Even one of the most well known .NET apps, Paint.NET, was fraught with Difficulties installing the application because of the massive .NET dependencies. If THEY have problems distributing a free app, what about the rest of the world? In the end, they had to Make a bootstrapper that installed Microsoft Installer 3.1, the .NET runtime bootstrapper, and all their other dependent libraires before they could install their own application.
So how about it. A linker. Do any good ones exist - or a tool that simply makes it possible to build a C# application without requiring that the user install the massive .NET runtime?
Update: so, it looks like there's a couple of options:
Mono:
.NET:
It looks like the Mono tools are getting use; how about the .NET based tools? Any other experience with them, or are we just going to have to wait for Microsoft to push it 3.5 out to everyone? I shudder to think how long it'll take for .NET 4.0 to be put out...
Source: (StackOverflow)
I'm interested in verifying if a given iPhone static library has been built for ARM or Intel.
It's more curiosity than anything. Is there some kind of Mac OS X or BSD specific tool to do this? This post gives an example in Linux.
Source: (StackOverflow)
You know, I haven't seen a good answer for this anywhere. Is it possible to embed a pre-existing DLL into a compiled C# executable (so that you only have one file to distribute)? If it is possible, how would one go about doing it?
Normally, I'm cool with just leaving the DLLs outside and having the setup program handle everything, but there have been a couple of people at work who have asked me this and I honestly don't know.
Source: (StackOverflow)
I've been programming in C++ for a while and I wondered how the compiler and linking process actually works?
Can someone explain please?
(Note: This is meant to be an entry to Stack Overflow's C++ FAQ. If you want to critique the idea of providing an FAQ in this form, then the posting on meta that started all this would be the place to do that. Answers to that question are monitored in the C++ chatroom, where the FAQ idea started out in the first place, so your answer is very likely to get read by those who came up with the idea.)
Source: (StackOverflow)
I am attempting to link an application with g++ on this Debian lenny system. ld is complaining it cannot find specified libraries. The specific example here is ImageMagick, but I am having similar problems with a few other libraries too.
I am calling the linker with:
g++ -w (..lots of .o files/include directories/etc..) \
-L/usr/lib -lmagic
ld complains:
/usr/bin/ld: cannot find -lmagic
However, libmagic exists:
$ locate libmagic.so
/usr/lib/libmagic.so.1
/usr/lib/libmagic.so.1.0.0
$ ls -all /usr/lib/libmagic.so.1*
lrwxrwxrwx 1 root root 17 2008-12-01 03:52 /usr/lib/libmagic.so.1 -> libmagic.so.1.0.0
-rwxrwxrwx 1 root root 84664 2008-09-09 00:05 /usr/lib/libmagic.so.1.0.0
$ ldd /usr/lib/libmagic.so.1.0.0
linux-gate.so.1 => (0xb7f85000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7f51000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7df6000)
/lib/ld-linux.so.2 (0xb7f86000)
$ sudo ldconfig -v | grep "libmagic"
libmagic.so.1 -> libmagic.so.1.0.0
How do I diagnose this problem further, and what could be wrong? Am I doing something completely stupid?
Source: (StackOverflow)
This warning:
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts
with use of other libs; use /NODEFAULTLIB:library
is a fairly common warning in Visual Studio> I'd like to understand the exact reason for it and the right way (if at all) to handle it.
This comes up in a debug build, compiled with /MDd. The project is linked to things like windows Version.dll and pdh.dll which themselves link with MSVCRT.dll. Obviously, I don't have the debug versions of these and can't compile them.
So I added /NODEFAULTLIB:MSVCRT to the linker command line and it actually did remove the warning. But what does this actually do? And why is it necessary?
Source: (StackOverflow)
Even trivially small Haskell programs turn into gigantic executables.
I've written a small program, that was compiled (with GHC) to the binary with the size extending 7 MB!
What can cause even a small Haskell program to be compiled to the huge binary?
What, if anything, can I do to reduce this?
Source: (StackOverflow)
I have been involved in some debate with respect to libraries in Linux, and would like to confirm some things.
It is to my understanding (please correct me if I am wrong and I will edit my post later), that there are two ways of using libraries when building an application:
- Static libraries (.a files): At link time, a copy of the entire library is put into the final application so that the functions within the library are always available to the calling application
- Shared objects (.so files): At link time, the object is just verified against its API via the corresponding header (.h) file. The library isn't actually used until run time, where it is needed.
The obvious advantage of static libraries is that they allow the entire application to be self-contained, while the benefit of dynamic libraries is that the ".so" file can be replaced (ie: in case it needs to be updated due to a security bug) without requiring the base application to be recompiled.
I have heard some people make a distinction between shared objects and dynamic linked libraries (DLL's), even though they are both ".so" files. Is there any distinction between shared objects and DLLs when it comes to C/C++ development on Linux or any other POSIX compliant OS (ie: MINIX, UNIX, QNX, etc)? I am told that one key difference (so far) is that shared objects are just used at run time, while DLL's must be opened first using the dlopen() call within the application.
Finally, I have also heard some developers mention "shared archives", which, to my understanding, are also static libraries themselves, but are never used by an application directly. Instead, other static libraries will link against the "shared archives" to pull some (but not all) functions/resources from the shared archive into the static library being built.
Thank you all in advance for your assistance.
Update:
In the context in which these terms were provided to me, I've found out the slight differences in these terms, which may even be just colloquialisms in my industry:
- Shared Object: A library that is automatically linked into a program when the program starts, and exists as a standalone file. The library is included in the linking list at compile time (ie: LDOPTS+=-lmylib for a library file named mylib.so). The library must be present at compile time, and when the application starts.
- Static Library: A library that is merged into the actual program itself at build time for a single (larger) application containing the application code and the library code that is automatically linked into a program when the program is built, and the final binary containing both the main program and the library itself exists as a single standalone binary file. The library is included in the linking list at compile time (ie: LDOPTS+=-lmylib for a library file named mylib.a). The library must be present at compile time.
- DLL: Essentially the same as a shared object, but rather than being included in the linking list at compile time, the library is loaded via
dlopen()/dlsym() commands so that the library does not need to be present at build time for the program to compile. Also, the library does not need to be present (necessarily) at application startup or compile time, as it is only needed at the moment the dlopen/dlsym calls are made.
- Shared Archive: Essentially the same as a static library, but is compiled with the "export-shared" flag. The library is included in the linking list at compile time (ie: LDOPTS+=-lmylib
S for a library file named mylibS.a). The distinction between the two is that this additional flag is required if a shared object or DLL wants to statically link the shared archive into its own code AND be able to make the functions in the shared object available to other programs, rather than just using them internal to the DLL. This is useful in the case when someone provides you with a static library, and you wish to repackage it as an SO. The library must be present at compile time.
Source: (StackOverflow)