Hi.
I've written a small static (Unix .a) library, as usual made from a bunch of .c and .h files. A lot of the functions in the .h files are internal to the final library. Only a few of the .h files containing the public interface.
How can I hide the internal names from people who will be using the library? I'd rather avoid giving silly prefixes to the internal stuff.
yours, Marcus
Jump to PostSupply a different .h file to people using the library than the one used to compile it.
Jump to PostIf the 4 .o files are inter-dependent (that is, you either have all of them or none of them), then you can use 'ld' to produce an incremental link of the 4 .o files to produce a single .o file (which you can then put in a library if you …
Supply a different .h file to people using the library than the one used to compile it.
Hi...
Supply a different .h file to people using the library than the one used to compile it.
Well, I'm pretty sure that is what I've done. The top level .h does not include the internal .h files (although the .c files the .o files were created from obviously do).
The problem is the the .a archive exports a load of symbols that can clash with user types/functions even though they are not in the header (unless I'm doing something really dumb, which I suspect I am). Using the strip utility to remove these stops the .a archive linking internally when it's compiled in to other projects.
The .a archive contains 4 .o files. Is there a way I can compile these into a single.o or .a file with just the symbols in the .h file shipped with it?
I'm currently poking around in the autoconf toolset to see how that does it, but that could take me days to figure out. I also want to avoid autoconf dependencies if I can.
Any ideas?
yours, Marcus
If the 4 .o files are inter-dependent (that is, you either have all of them or none of them), then you can use 'ld' to produce an incremental link of the 4 .o files to produce a single .o file (which you can then put in a library if you want).
ld also has many options for manipulating the symbol table, so you should be able to emit only the public API when you're done.
If all the functions are in one *.c file then you can declare all the internal functions with the static keyword and the symbols will not appear in the libraries or be accessable outside the *.c file.
Hi...
If the 4 .o files are inter-dependent (that is, you either have all of them or none of them), then you can use 'ld' to produce an incremental link of the 4 .o files to produce a single .o file (which you can then put in a library if you want).
ld also has many options for manipulating the symbol table, so you should be able to emit only the public API when you're done.
Excellent. I'll read the docs on ld. I thought there had to be something like this.
Cheers.
yours, Marcus
Hi...
If all the functions are in one *.c file then you can declare all the internal functions with the static keyword and the symbols will not appear in the libraries or be accessable outside the *.c file.
I'm afraid they are not. It's a good few hundred lines of code (there are actually already internal statics as well), so I'd like to keep them separate.
yours, Marcus
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.
