On the private symbol issue... there is probably a solution to this already. You can partially link a bunch of object files into a single object file (see ld -r). After this is done, 'strip' the file except for those symbols marked with non-hidden visibility- I've not tried to do this, maybe 'strip -x' does the right thing? Not sure.
The .a file is a relic: Why static archives were a bad idea all along
81–90 of 136 posts
Re: The .a file is a relic: Why static archives were a bad idea all along
#82> Yet, what if the logger’s ctor function is implemented in a different object file? This is a contrived example akin to "what if I only know the name of the function at runtime and have to dlsym()"? Have a macro that "enables use of" the logger that the API user must place in global scope, so it can write "extern ctor_name;". Or have library specific additions for LDFLAGS to add --undefined=ctor_name There are worka…
Also, don’t use automatic module init, make the user call an init function at startup. And prefix everything in your library with a unique string.
What if you use two libraries A and B that both happen to use library C under the hood? Is the application expected to initialize all dependencies in the right order at the top level? Or is library initialization supposed to be idempotent?
This all works as long as libraries are “flat”, but doesn’t scale very well once libraries are built on top of each other and want to hide implementation details.
Re: The .a file is a relic: Why static archives were a bad idea all along
#83Earlier quoted context omitted.
How can they be expected to learn this, when it is now fashionable to treat C and C++ as if they are scripting languages, shipping header only files? We already had scripting engines for those languages in the 1990's, and the fact they are hardly available nowadays kind of tells of their commercial success, with exception of ROOT.
It makes more sense for c++ due to templates, but the header only C library trend is indeed very strange. It's not surprising that people are coming up now who are writing articles about being confused by static linking behavior.
It's not strange at all. You only have one file to keep track of and it does everything, you put the functions in any compilation unit you want, C compilation is basically instant, and putting a bunch of single file libraries into one compilation unit simplifies things further.
Re: The .a file is a relic: Why static archives were a bad idea all along
#84Earlier quoted context omitted.
Also, don’t use automatic module init, make the user call an init function at startup. And prefix everything in your library with a unique string.
What if you use two libraries A and B that both happen to use library C under the hood? Is the application expected to initialize all dependencies in the right order at the top level? Or is library initialization supposed to be idempotent? This all works as long as libraries are “flat”, but doesn’t scale very well once libraries are built on top of each other and want to hide implementation details.
The call to init should be idempotent
Re: The .a file is a relic: Why static archives were a bad idea all along
#85> Yet, what if the logger’s ctor function is implemented in a different object file? Well, tough luck. No one requested this file, and the linker will never know it needs to link it to our static program. The result? crash at runtime.
If you have spontaneously called initialization functions as part of an initialization system, then you need to ensure that the symbols are referenced somehow. For instance, a linker script which puts them into a table that is in its own section. Some start-up code walks through the table and calls the functions.
This problem has been solved; take a look at how U-boot and similar projects do it.
This is not an archive problem because the linker will remove unused .o files even if you give it nothing but a list of .o files on the command line, no archives at all.
Re: The .a file is a relic: Why static archives were a bad idea all along
#86Isn't this what partial linking is for, combining object files into a larger one?
Re: The .a file is a relic: Why static archives were a bad idea all along
#87> Yet, what if the logger’s ctor function is implemented in a different object file? This is a contrived example akin to "what if I only know the name of the function at runtime and have to dlsym()"? Have a macro that "enables use of" the logger that the API user must place in global scope, so it can write "extern ctor_name;". Or have library specific additions for LDFLAGS to add --undefined=ctor_name There are worka…
Also, don’t use automatic module init, make the user call an init function at startup. And prefix everything in your library with a unique string.
Agree, there should be a prefix. But if 2 of my dependencies didn't use a prefix, why is it my fault when I fail to link against them?
Also, some managers object to a prefix within non-api functions, and frankly I can understand them.
Re: The .a file is a relic: Why static archives were a bad idea all along
#88.so .o .a .pc holy shit, what a mess Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system
> Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system This is such an ignorant comment. Most other natively compiled languages have exactly the same concept behind: Object files, Shared Libraries, collection of object and some kind of configuration description of the compilation pipeline. Even high level languages like Rust has that (to some extend). The…
I think people today often do not understand any more that C like many other things in the UNIX world is a tool, not a complete framework. But somehow people expect a complete convenient framework with batteries included. They see it has a deficiency that C by itself does not provide many things. I see it as one of its major strengths and this is one of the reasons why I prefer it.
Re: The .a file is a relic: Why static archives were a bad idea all along
#89On the private symbol issue... there is probably a solution to this already. You can partially link a bunch of object files into a single object file (see ld -r). After this is done, 'strip' the file except for those symbols marked with non-hidden visibility- I've not tried to do this, maybe 'strip -x' does the right thing? Not sure.
1. "Advanced" compilation environments (meson) probably limit this ability to some extent.
2. Package managers (rpmbuild for instance) mandate build with debug symbols and they do the strip on their own so to create the debug packages. This limits our control of these steps.
Re: The .a file is a relic: Why static archives were a bad idea all along
#90Library files are not the problem, deploying an SDK as precompiled binary blobs is ;) (I bet that .a/.lib files were originally never really meant for software distribution, but only as intermediate file format between a compiler and linker, both running as part of the same build process)
Yeah, but when the product is an SDK, and customers develop on top of it (using their own toolchains) there isn't a lot left for me to play with.