Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The .a file is a relic: Why static archives were a bad idea all along

medium.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: The .a file is a relic: Why static archives were a bad idea all along

#131

Post by CyberDildonics »

pjmlp wrote: post #127
CyberDildonics wrote: post #83

Earlier quoted context omitted.

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.

That might be why back in 1999 - 2002, I was waiting around 1h for each OS build variant of our product, a mix of Tcl and C native libraries, super fast. It is only basically instant in toy examples, or optimizations completely disabled.

Sqlite is 6 MB and can compile in 2 seconds on msvc.

It's 25 years later, if you are waiting for an hour to compile a single normal C program, there is a lot of room for optimization. Saying C doesn't compile fast because 25 years ago your own company made a program that compiled slow is pretty silly.

Single file C libraries are fantastic because they can easily all be put into more monolithic compilation units which makes compilation very fast and they probably won't need to be changed.

Have you actually tried what I'm talking about? What are you trying to say here, that you think single file libraries would have made your 1 hours pure C program compile slower?

Re: The .a file is a relic: Why static archives were a bad idea all along

#133

Post by asveikau »

CyberDildonics wrote: post #131
pjmlp wrote: post #127

Earlier quoted context omitted.

That might be why back in 1999 - 2002, I was waiting around 1h for each OS build variant of our product, a mix of Tcl and C native libraries, super fast. It is only basically instant in toy examples, or optimizations completely disabled.

Sqlite is 6 MB and can compile in 2 seconds on msvc. It's 25 years later, if you are waiting for an hour to compile a single normal C program, there is a lot of room for optimization. Saying C doesn't compile fast because 25 years ago your own company made a program that compiled slow is pretty silly. Single file C libraries are fantastic because they can easily all be put into more monolithic compilation units which…

I used to compile sqlite regularly on msvc and it was more than 2 seconds. If this is a measurement it is a recent one with recent hardware.

Sqlite is a single compilation unit for much very different reasons than the header only libraries by the way. It's developed as many different files and concatenated together for distribution because the optimizer does better for it that way.

Re: The .a file is a relic: Why static archives were a bad idea all along

#134

Post by CyberDildonics »

asveikau wrote: post #133
CyberDildonics wrote: post #131

Earlier quoted context omitted.

Sqlite is 6 MB and can compile in 2 seconds on msvc. It's 25 years later, if you are waiting for an hour to compile a single normal C program, there is a lot of room for optimization. Saying C doesn't compile fast because 25 years ago your own company made a program that compiled slow is pretty silly. Single file C libraries are fantastic because they can easily all be put into more monolithic compilation units which…

I used to compile sqlite regularly on msvc and it was more than 2 seconds. If this is a measurement it is a recent one with recent hardware. Sqlite is a single compilation unit for much very different reasons than the header only libraries by the way. It's developed as many different files and concatenated together for distribution because the optimizer does better for it that way.

If this is a measurement it is a recent one with recent hardware.

This was on a 10 year old Xeon CPU.

Sqlite is a single compilation unit for much very different reasons than the header only libraries by the way. It's developed as many different files and concatenated together for distribution because the optimizer does better for it that way.

What difference does that make? What does it have to do with anything? You could develop anything like that.

The point here is that single file libraries work very well. If anything they end up making compilation times lower because they can be put into monolithic compilation units. When I say single file C libraries, I'm talking about single files that have a header switch to make them header declarations or full functions implementations. I'm not sure what you're trying to say.

Re: The .a file is a relic: Why static archives were a bad idea all along

#135

Post by nly »

sherincall wrote: post #21
EE84M3i wrote: post #20

Something I've never quite understood is why can't you statically link against an so file? What specific information was lost during the linking phase to create the shared object that presents that machine code from being placed into a PIE executable?

wcc can do that for you: https://github.com/endrazine/wcc

There's no also lief: https://lief.re/doc/latest/tutorials/08_elf_bin2lib.html

Re: The .a file is a relic: Why static archives were a bad idea all along

#136

Post by rurban »

TuxSH wrote: post #11

> This design decision at the source level, means that in our linked binary we might not have the logic for the 3DES building block, but we would still have unused decryption functions for AES256. Do people really not know about `-ffunction-sections -fdata-sections` & `-Wl,--gc-sections` (doesn't require LTO)? Why is it used so little when doing statically-linked builds? > Let’s say someone in our library designed th…

It's heavily use in embedded only
Post reply on HN