As I've mentioned in other posts, I track the SVN branches of both LFS and BLFS. Being on the bleeding edge, things sometimes go awry but the challenge comes from repairing the damage and learning from it.

With the release of glibc-2.18 recently and now making the Changelog of LFS-SVN, I opted to build it, run make check (just the expected errors) and then go ahead and install it.

Absolute everything is working fine with the sole exception of acroread, which segfaults immediately. Rolling back to the predecessor, 2.17, resolves this error. By the way, even though the command line reader fails with that error the broswer plugin works fine with glibc-2.18.

I run a multilib system and, of course, acroread is among the tiny handful of 32-bit apps on what is largely a 64-bit platform. I know I built the 32-bit variant correctly since other 32-bit apps, such as wine work faultlessly.

Has anyone else experienced errors after migrating to glibc-2.18 with acroread or anything else?

Can't say I have as I run a pure 64-bit OS and don't use Acroread myself, but have you submitted an inquiry to Adobe regarding the bug?

Have you tried checking to see if a logfile is create for Acroread and if there's a possible chance it is looking for a specific file from glibc-2.17 that may have a version control number that 2.18 might not have? I've ran into this before as a compatibility issue with some closed-source software only to discover I had to create a sym-link to a file before it would read it and work. After creating it, the software worked as normal.

I've defaulted due to my 64-bit architecture with xPDF for now.

With glibc-2.18 being so new, I've opted to take a wait and see stance for now which is the reason for posting the initial message. I wanted to get at least one other confirmation to make sure it's not just peculiar to my system. And with Adobe largely dismissing Linux as a second class platform, odds are that a bug report for a new glibc library wouldn't be of much interest.

And, along the lines that you mentioned, acroread is far less important to me than it used to be. KDE's okular has really matured nicely and is now my go-to application for PDF as well as DVI and other file formats.

I've come across few instances where a simple version-up of glibc did posed major issues with compatibility. Usually, it's a missing sym-link, or often it could be a rouge compile flag, missing compatibility patch, or some other not-yet-determined issue at hand, but usually those are found quickly enough.

Yes, Adobe does foolishly pass-off UNIX and UNIX-like systems, with the exception of Apple OS-X which they oh-so-willingly brown-nose.

For now, unless absolutely needed, I'd recommend rolling back to 2.17 if you have to have the compatibility, otherwise, find alternatives that work just as well, if not better, and choose them.

I've explored this a bit more and have a few very preliminary conclusions. On a somewhat dated LFS system that I have on VirtualBox, acroread works fine with the new glibc-2.18. That system is a pure 32-bit platform which is one difference between it and my everyday work multilib environment. And, perhaps significantly, given the age of that LFS system (circa spring 2012), the compiler is gcc-4.6.3 whereas my primary system uses gcc-4.8.1. Also of possible relevance is that the former system uses kernel 3.9.5.

I'm going to explore this further by building glibc-2.18 with gcc-4.8.1 on that pure 32-bit, slightly older system to see what happens. Then, I'll upgrade the kernel as well.

Whatever happens, it's a great learning experience and I'll post my findings here. After over a decade of "scratching", I've not yet encountered a situation that hasn't been resolved...with some time and effort.

Thanks for the response and, off topic for this thread, your interest in OpenRC, has also triggered a similar interest with me. Now that I've successfully converted all of the boot scripts to dash, the next challenge will be to explore OpenRC.

This is turning out to be really "interesting". Here are my findings:

1). On a multilib LFS-SVN VirtualBox system (emulating an i2-core) with 10 GB of RAM allocated with 12 GB of swap, the new glibc-2.18 works perfectly with all 64-bit applications tried and with all 32-bit applications, including acroread. The VirtualBox system pretty much shadows what I do on the real platform, an i7-3770K with 32 GB of real RAM and 12 GB of swap.

2). But on the real systems, including a pure 32-bit LFS-7.2 system and my primary LFS-SVN multilib system, glibc-2.18 always fails with acroread producing this fault caught by the kernel:

Running strace reveals that the SIGSEGV happens right after a call to brk().

Rolling back to the immediate predecessor version (glibc-2.17) produces no errors on either the pure 32-bit platform or the multilib system.

3). And here's where it gets even more puzzling. When I build glibc-2.18 on the real system and then transport it over to the VirtualBox guest, everything works fine. This indicates that the compile is good on the host. But, conversely, when glibc-2.18 as compiled on the guest where it works without fault and then transported back to the host, the general protection fault cited above occurs.

Based on my experiments, the indications are that 32-bit glibc-2.18 (built with no CFLAGS) is somehow incompatible with my hardware:

ASUS P8Z77-V LX
Ivy Bridge i7-3770K LGA 1155
4 modules (32 GB) of 8192MB 1333MHz Synchronous DDR3 DIMM, AMI CMX8GX3M1A1333C9

I plan to explore this further and any more "try this, try that" suggestions are welcome. Oh, by the way, the only two errors I get with "make check" on glibc-2.18 are:

First of all, the problem with 32-bit applications and glibc-2.18 is not just limited to acroread. A numerically intensive antenna modeling tool, 4nec also segfaults. That motivated me to pursue the matter of that current GNU system library and my hardware with more zeal.

Taking a cue from the glibc.SlackBuild which uses an i486 triplet for building, I did likewise, passing the following to configure:

And that resolved the problem of segfaults on 32-bit apps. Later I change the triplet to i586-pc-linux and it was still good. The error occurs with the i686-pc-linux triplet (the default if unspecified).

Watching the build process, the host triplet governs which system dependent source is used for glibc. Its subdirectory tree is structured as "i386/{i486,i586,i686}" for such system dependencies, most of which is written in assembly. Backing off from the i686 arch to a more conservative i586 or i486 hauls in less aggressive code at compile time. I've not narrowed down which file(s) might be the culprit opting to stick with i586 since it "works for me!" [TM]

Note that I can pass aggressive CFLAGS to the build: with no ill-effect. Methinks that the i7-3770K isn't compatible with one or more of the instruction in the "i386/i686" assembly code but "i386/i586" works without fault.

I'll let the glibc maintainers know of my findings. They may want me to perform some tests on that platform to narrow down the precise cause.

Slackware defaults to i486 for a lot of compatibility reasons. Stick to i486 and you should be fine.

I would argue against using the -O3 flag and instead use -O2 flag for stability and compatibility reasons.

Here's how the story unfolds further and ultimately has a happy ending. Contrary to conventional wisdom, using "-O3" for optimization actually fixes the problem. No, it's not just gratuitous "ricing" but by doing so, one of the problematical functions is then inlined. Along with a dose of trial and error followed by some additional reading, this thread from Arch confirmed my findings:

https://bugs.archlinux.org/task/36556?project=1

And here's the trivial patch which adds the inline keyword to the function: