Is it possible to link to non-external symbols, or convert them to external symbols?
I only ask because a (big) library I want to use has a nightly build, but with stripped symbols. I'd prefer to use the nightly, rather than spend half a day compiling it.
Stripped library only means that debugging symbols were stripped out. The rest of the library is in place. The trouble you might encounter linking to such library is a linker warning about missing debugging symbols. Another problem you might get with a stripped library is debugging without proper debugging symbols, that's little fun.
To the question of external/non-external (do you mean exported?) symbols, if you are linking to the static library, it doesn't need to define any 'exports' as it gets linked to your code just as a big object file. Linking to the dynamic library, slightly differs depending which platform you're interested in. On windows your dll needs to declare function you want to use as (declspec) __dllexport. On linux if memory serves me, there's no need to declare anything like that and you can use your functions from .so file as if they would be in your code, similar in a way to the static libraries.
Update:
Alex, I'm not 100% sure, but I believe, what I wrote about linux applies to OS X in this case. For as long as you have a header file with function declarations you should be able to use them just fine. If you don't have some functions in the provided header file, but have access to sources, you could create your own. It is however a fairly bad idea, since authors of the SDK didn't want to give you access to those functions and didn't add them to public header files, so they are free to modify their functionality as they see fit at any time, potentially leaving you with non-working code and a need to rewrite/redesign certain things. Same applies to all "undocumented" functions, they may be modified or removed and if it causes you a problem, you are the only person guilty, and the only person who would care. Proceed with caution.
No. It is not possible to link to non-external symbols.
By definition, non-external symbols are not exported from the compiler/assembler/whatever to the linker. Those symbols are gone, vanished from the universe, only a fading memory, by the time the linker sees the module(s) to be linked.
Back in the Early Iron Age, when computers were still made from discrete transistors, compilers and assemblers could be commanded to print symbol tables for each module. Today, we call that "debug information", it is generally NOT printed, but stored somewhere that debug tools can find it in the load module. And it is precisely what is being stripped out of your nightly build.
What is it that you are trying to do? If you are trying to access routines (or variables) in the library that are explicitly non-external, well, there's probably a good reason they are non-external. Talk to the maintainers of the library, explain why you want access to those routines (or variables), and LISTEN to their explanations of why they didn't provide that access.
I'm inclined to say no, as long as the question is this general.
The linker may for instance perform caller/callee optimizations on internal functions that it can't for external functions. E.g. it may detect that none of the callers care about the preservation of a certain register, and optimize out the saving of taht register in the callee prolog code.