2 ms·
It's not that hard. You have libc.so.42 with 64 bit intmax_t. You change stdint.h to say intmax_t is 128 bits. You compile a new libc and install libc.so.43. Ne
by tedunangst 5y ago
It's not that hard. You have libc.so.42 with 64 bit intmax_t. You change stdint.h to say intmax_t is 128 bits. You compile a new libc and install libc.so.43. New programs and libraries that get compiled link with the bigger intmax_t, existing programs continue loading the older libc. But there's a strange resistance to omg how can we possibly have two versions of libc installed at the same time.
- int_19h 5y agoHaving two versions of libc installed is not the problem. The problem is when you link to two different libraries in your app that link to two different (and ABI-incompatible) versions of libc.
- tedunangst 5y agoVersioning doesn't solve that problem. I call time() in my new code. I call some library which eventually calls futimes(). Everybody along the way needs to agree on the size of time_t. The library can't correctly use the old symbol even if it's available.
- int_19h 5y agoOn Linux, you're correct, but only because the symbol namespace is global. On Windows, every DLL with a different name also has its own distinct symbol namespace. Thus, the conflict you describe can only arise if your code explicitly propagates some time_t* value from one library to the other.