GLIBC 2.16 Brings X32 Support, ISO C11 Compliance, Better Performance

An anonymous reader writes "The GNU C Library version 2.16 was released with many new features over the weekend. The announcement cites support for the Linux x32 ABI, ISO C11 compliance, performance improvements for math functions and some architectures, and more than 230 bug fixes."

Comments

Re:32-bit pointers in x32?

[tchernobog]

If you can point me to a spreadsheet program that opens both ODS and XSLX files, is feature complete with respect to the OOXML formula specification, doesn't cost more than 100 € and runs on GNU/Linux, I will consider it :-p. Of course, it should work *better* than LibreOffice.

I ain't saying LibreOffice shines on this. I should really take the time to profile it and file a bug against it. But it works most of the time for me and gets the job done better than many other alternatives. The fact that it uses *a lot* of memory for really complex models (we are talking about a million computed cells or so, anyways), should be fixable in the long run.

Re:X32

[SuneSpeg]

If someone could explain to me why x86 architecture is suddenly named x32 , i would be happy too. The name has been working fine for 40 years, despite its difficult teen years where it only represented 16bit.

Re:X32

[ThePhilips]

The negatives:
* On a mixed x86-64 and X32 system, you have to load two copies of shared libraries (this doesn't happen with exclusively X32 systems).

It's not that the extra copies is the problem.

The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.

After enjoying it thoroughly on the commercial *nix variants (Solaris and HP-UX), I have hopes that Linux will not do it and keep it clean: either fully 64bit system or fully 32bit system.

Re:X32

[BusterB]

In my opinion, it is designed pimarily so that Intel's embedded processors run Android well in the short term. Atom architecture in particular benefits in that some pointer offset calculations are faster when done in 32-bit vs 64-bit. Here are some great discussion links: http://blog.flameeyes.eu/2012/06/debunking-x32-myths http://lwn.net/Articles/503412/

Re:X32

[kantos]

Actually no it's not... Linux has that already and it works just fine, anyone who has gone through the pain of getting flash player to work before the x64 port can tell you. This is actually more similar (albeit with more restrictions) to setting the /LARGEADDRESSAWARE:NO option on the linker in Visual C++. An option you'll notice that comes with a significant warning about interoperability. Microsoft solved this problem by making pointer handling the developer's job, this meant that they could continue to use x86-64 libraries without an issue but all malloc operations would return addresses that are safe to sign extend.

The benefit on windows is that you:

1. Use less ram on an x64 bit OS than a corresponding x86 application would, this is because you won't have x64 threads for each x86 thread you have going, and won't have to load the thunking DLLs
2. In theory could interop with x86 code since your pointers are safe, however this is not supported

Re:X32

[ThePhilips]

Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).

I should have spelled it out better: many pieces of software already now make a presumption what /usr/lib is: some insist that those must be 32bit libraries, some insist on the 64bit ones. LD_LIBRARY_PATH works most of the time - until you hit an application which to do its work launches other applications.

As for the headers... I have seen enough breakages to stop believing that #ifdefs are the solution: different software and different systems refer to the same thing with under names. Good luck finding a working combination. E.g. some functions are available in 32bit variant but not in 64bit variant, and vice versa. (That was recent fsck up of compiling VIM on the AIX 7: compile as 32bit, _XOPEN_SOURCE=600 - and it would fail linking because some 32bit libs are missing; try to compile as 64bit - only to find that _XOPEN_SOURCE wouldn't work and piles and piles of function declarations are missing. I had to hack the includes/defines into the config.h for the VIM to compile and link. (autoconf hasn't spotted it because it apparently couldn't imagine the functions missing.))

Linux now is more or less clean of the madness.