The man page for realpath on my Linux box says:
VERSIONS
On Linux this function appeared in libc 4.5.21.
Now what does that mean? To which libc is it referring - "Linux libc"? - and where can I find a list that matches up the different libc flavors, so I can see what the minimum requirements are to link to this function and others?
GLIBC is at version 2.13, which is considerably lower than 4.5.21, but the Wikipedia page about glibc says:
In the early 1990s, the developers of
the Linux kernel forked glibc. Their
fork, called "Linux libc", was
maintained separately for years and
released versions 2 through 5.
... and
The last used version of Linux libc
used the internal name (soname)
libc.so.5. Following on from this,
glibc 2.x on Linux uses the soname
libc.so.6
Does that imply that any glibc is equivalent to a "Linux libc" with a major version higher than 5?
There are other man pages referencing this or that version of "libc", so realpath is merely one example for problem at large.
Note: the code I am building is not limited to Linux, that's why I need a definite method to detect whether a certain function is available.
glibc, although at version 2.x, was for many years referred to as "libc6" for compatibility with the versioning scheme of the old libc3/4/5. In any case, the man pages on a Linux system are very helpful, but not necessarily canonical. glibc uses the "info" system instead of man pages, thus for glibc functions, you may be better off looking at the glibc manual than the man pages. While the bugs category on the realpath function is interesting in a historical context, unless you're targeting libc5 systems (which, surely you're not) is not particularly helpful.
Related
Due to OSX having out of date openssl versions, i need to bundle more up to date copies of libssl and libcrypto with my application.
The bundled versions i distribute do appear to work on very recent systems (My own system and the system i built these libraries on is a 2015 MBP) - but on some other systems I get an 'illegal instruction' error using those bundled libraries.
My questions are:
(1) Are the illegal instructions happening because an advanced instruction (such as AVX-512) are being used by the binary, and this instructions doesn't exist on some systems?
(2) How do i build versions of libssl and libcrypto that can be bundled and used by the vast majority of relatively recent apple systems? (without causing illegal instructions..)
(1) Are the illegal instructions happening because an advanced
instruction (such as AVX-512) are being used by the binary, and this
instructions doesn't exist on some systems?
It depends, and you probably need to show the code that's causing them. In the past OpenSSL used CPU feature probes to see what was available on all (nearly all?) platforms. Also see questions like SSL_library_init cause SIGILL when running under gdb.
In the latest sources OpenSSL does not perform CPU feature probes on Apple platforms because a SIGILL trashes memory. It is some sort of Apple bug and it affects Botan, Crypto++, OpenSSL and others probing the cpu. (All the listed libraries moved away from Apple feature probes). That's a recent change, however. Also see OpenSSL PR 3108, SIGILL-free processor capabilities detection on MacOS X.
(2) How do i build versions of libssl and libcrypto that can be
bundled and used by the vast majority of relatively recent apple
systems?
If you are not doing so, use the latest OpenSSL. That should avoid the cpu feature probes on Apple platforms.
The library also uses -force_cpusubtype_ALL, so the compile should target the least capable machine in a class of cpu's. That should be enough to avoid instructions not available on later cpu's.
If the project is using AVX-512, then it's use is certainly guarded at runtime. My guess is the guard likely checks the result of CPUID. We would need to see the code in question that is using AVX-512 instructions and causing the SIGILL to say more. But like I said, it is only a guess until we see the code.
I am asking here because I have no idea where to find any information about this problem. If you could recommend me a book or an article about it, I would be pleased.
Where can I find any information about correlation between Linux kernel and GLIBC's version? I know that, the kernel itself contains implementation of libc's functions, but I do not know, how they are delivered to it.
For example:
Recently I had to build the kernel for an old PowerPC processor. It came with libc's dynamic library files in version 2.3.6 out-of-the-box. In /lib/ path there are files with names like librt.so-2.3.6.
What is the simplest way to update this lib to a newer version?
Is it possible to configure kernel's build system to make it generating uImage file with a newer GLIBC version or an alternative one (ex. EGLIBC)?
There is little correlation, the same kernel should work with a wide range of glibc versions, and viceversa. The library finds out what the kernel handles, and uses that. For the gory details of what has changed in glibc (this is what you interact with, including support for new kernel features), you should look at the upstream changelog. For new features in the Linux kernel, perhaps the best source are the periodical "What's new in..." articles the kernel section of LWN
I was looking at a question about atomic compare and swap and gcc intrinsics. I noticed that an answer quoted from the gcc manual (note the answer I looked at quoted from an earlier version of gcc but I've linked to the latest versions manual because I had checked to see if anything changed). However, when I looked at the text in the manual I saw that it appears to reference Itanium rather than x86:
The following builtins are intended to be compatible with those
described in the Intel Itanium Processor-specific Application Binary
Interface, section 7.4. As such, they depart from the normal GCC
practice of using the “__builtin_” prefix, and further that they are
overloaded such that they work on multiple types.
My question is why does gcc reference Itanium documentation and does that effect how the intrinsics work on x86? Are there any differences or is it safe to assume that even though the gcc manual references the Itanium manual that everything the gcc manual describes will work correctly on an x86 system?
My understanding is that a lot of gcc's ABI decisions (the egcs fork) were based on the ABI specs for the good ship Itanic. This included the name mangling conventions for C++ symbols. There was a large effort (Project Trillian) to have IA-64 Linux (and GCC) ready to go when the actual processor became available. The semantics are intended to be platform-independent, though they will be replaced by the __atomic builtins.
This question was emerged from this question.
The problem is that there is a NVidia driver for Linux, compiled wth GCC 4.5. The kernel is compiled with GCC 4.6. Well, the stuff doesn't work because of the version number difference between GCCs. (the installer says the driver won't work - for details please visit the link above)
Could one disguise a binary compiled with GCC 4.5 to a binary compiled with GCC 4.6? If it is possible, under what circumstances would it work well?
Your problem is called ABI: Application Binary Interface. This is a set of rules (among others) how functions in a piece of code get their arguments (ordering, padding of types on the stack), naming of the function so the linker can resolve symbols and padding/alignment of fields in structures.
GCC tries to keep the ABI stable between compiler versions but that's not always possible.
For example, GCC 4.4 fixed a bug in packed bit-fields which means that old/new code can't read structures using this feature properly anymore. If you would mix versions before and after 4.4, data corruption would occur without any crashes.
There is no indication in the 4.6 release notes that the ABI was changed but that's something which the Linux kernel can't know - it just reads the compiler version used to compile the code and if the first two numbers change, it assumes that running the code isn't safe.
There are two solutions:
You can compile the Nvidia driver with the same compiler as the kernel. This is strongly recommended
You can patch the version string in the binary. This will trick the kernel into loading the module but at the risk of causing data corruption to internal data structures.
In an attempt to build 64-bit PicoLisp on Mac OS X (10.6.7) it seems I've encountered a problem with the OSX Dev. Tools GNU assembler ('as'), which is version 1.38. My Xcode is version 3.2.4. The lines in my (generated) x86-64.darwin.base.s that cause the problems typically look like this:
call foo#plt
... and they give me error messages like this:
x86-64.darwin.base.s:41694:junk `#plt' after expression
64-bit PicoLisp builds without problems on Linux and SunOS. These platforms probably have more capable (newer) versions of GNU assemblers. I don't know if newer GNU assemblers are avilable for OSX/Darwin ... or could there be other solutions?
If you'd like to try this yourself on OSX/Darwin, I can give you some files that are needed.
Unfortunately, I think there are at least two significant issues here:
"PLT" is an ELF concept, but OS X uses a completely different object / executable file format - Mach-O. Mach-O uses a similar mechanism but with a different name.
MacOS prefixes asm symbol names with a leading underscore. So you want call _foo. call foo would assemble but not link. As on GNU/Linux (ELF), the linker indirects through dyld_stub entries for you when you call a symbol that turns out to be in a dynamic library.
(Non-interposable symbols are the default even when building shared libraries, unlike on ELF systems)
Apple's as appears to be derived from a fork of a much earlier version of the GNU assembler, and, in some places, the syntax (and command line options) are rather different from recent versions (even where the concepts are the same).
It looks like there has been some work on i386 and x86-64 Mach-O support quite recently in binutils; it might be worth investigating the most recent version (2.21). But if the generated assembly code is trying to do clever things which are ELF-specific, you're probably going to have some major problems anyway...
PicoLisp has been supported on Mac for quite some time now. Just go to the standard download site.