[Rob Hicks]

for Johannes Leimert's problem:

example.c:8:10: fatal error: stdio.h: No such file or directory #include <stdio.h>

See https://stackoverflow.com/questions/...e-or-directory to install development libraries to allow this to compile.

Also, given that the latest Ubuntu LTS release (18.04) is afflicted with this issue, it seems like moving forward everyone in the Linux world is impacted and one can only hope Stata will wake up and fix this.

[Nicolai Suppa]

Hi,

thanks for sharing the fixes and also for sharing some background information on this issue.

thanks to the script of Kyle Barron (https://github.com/kylebarron/stata-png-fix) Stata 14.2 and 15.1 now start up with icons on my Ubuntu 18.04 machine. However, as previously mentioned by Rob (in #4), this workaround breaks some Stata functionalities requiring more recent versions of the library.

What I found particular annoying is that I no longer could call the pdf documentation from within Stata: Nothing happened: Evince, my pdf viewer, didn't start (whether called from Stata's viewer or from the menu). Running Stata from the terminal revealed

 evince: error while loading shared libraries: libpng16.so.16: failed to map segment from shared object

One way to address at least this issue is to force evince to use the more recent versions of the library. As Stata for unix comes with the stata_pdf text file in its directory, adding the path of the more recent libraries prior to calling evince worked for me.

Just in case somebody runs into a similar problem, this is my stata_pdf

case "$PDFVIEWER" in
"")    cmd="evince"
    ;;
*)    cmd="$PDFVIEWER"
    ;;
esac

case "$1" in
"-page")    pagenum=$2
        fname=$3
        wharg="--page-index=$pagenum"        
        # wharg="/a page=$pagenum"
        ;;
"-section")    section=$2
        fname=$3
        wharg="--named-dest=$section"        
        # wharg="/a nameddest=$section"
        ;;
*)        fname="$1"
        wharg=""
        ;;
esac
        
LD_LIBRARY_PATH=/usr/lib exec $cmd $wharg "$fname"

Finally, I think fixing missing icons, possibly at the cost of reduced functionalities, is nothing Stata users should have to worry about.

[Chinh Nguyen (StataCorp)]

Unfortunately, unlike Stata itself, Linux libraries aren't always designed to be backward compatible. Stata uses GTK+ 2 for creating it's graphical user interface. Stata asks GTK+ 2 to load Stata's icons. GTK+ 2 uses libpng to read the icons and the version of libpng it wants to use must be installed. The version of GTK+ 2 Stata links against is using an older version of libpng which is causing the problem many of you have are encountering. We link against this older version of GTK+ 2 to support our users who are still running older linux distributions including many of our enterprise users who are unable to upgrade their linux distros.

The problem for us is this: switch to a newer version, and hear of problems from everyone with the older version; remain with the older version, and hear of problems from everyone with the newer version. Statically-linking a particular version can also be problematic. In the future we may simply provide multiple distributions for multiple 'ages' of Linux.

[larsvilhuber]

The same way that Stata comes packages with its own, locked-in version of Java (utilities/java), I don't see you couldn't package up the fix that I and others in this forum have developed (which ultimately downloads a custom libpng library and makes it available to Stata) as part of the Stata install. Or update the install script to detect the version of libpng and deploy such a package, only when needed.

I agree that there are many old and new versions of Linux in production. I personally run (on various systems) 4 of them. It would be pretty straightforward (and cheap) to provide two versions of Stata binaries, for various vintages of libpng. You can then measure the downloads and update pulls from your website to see when the use of the really old versions becomes marginal.

You will always run into the issue that enterprise users have older versions of Linux than academic and other "enthusiasts". The latter are more vocal publicly. The former are more vocal financially. Keep a reasonable support for old versions around in the base price, and then, if enterprise users need continue maintaining older versions, have them pay extra.

[Claudio Leite]

There's an extra step you can take after building the patched libraries that eliminates the need to set LD_LIBRARY_PATH. This will help restore compatibility with programs started from within Stata. This was mentioned in post #4 earlier in this thread, with the example of pdflatex.

You'll need to build patchelf from the Nix project: https://github.com/NixOS/patchelf. The current Git version is necessary. The latest release, 0.9, will not work for this.

Patchelf can update the RPATH of an executable, which will instruct the system where to look for shared libraries much like LD_LIBRARY_PATH. This is sort of baking the path into the executable. The trouble is that Stata itself isn't the one loading libpng16.so.16; Gdk-Pixbuf is the library that needs it and messes up the icons. RPATH won't work for this, but you can work around it by using another Patchelf command to make Stata depend on libpng16.so.16 itself. That way it is already loaded from our RPATH before Gdk-Pixbuf needs it.

Assuming your Stata binaries are in $HOME/local/stata and the patched libraries are in $HOME/local/stata-png-fix, the steps will look something like this:

cd $HOME/local/stata
patchelf --set-rpath $HOME/local/stata-png-fix xstata
patchelf --add-needed libpng16.so.16 xstata

You can check that this worked by running

ldd xstata | grep libpng

You should see entries for both libpng12 and libpng16, and libpng16 should be coming from your stata-png-fix directory. Make sure LD_LIBRARY_PATH is not set, otherwise the test will be invalid.

You should then be able to launch ./xstata without a wrapper script and without setting LD_LIBRARY_PATH. Repeat for xstata-se and xstata-mp.

After doing this, I have XStata with proper icons, and can launch pdflatex from a shell started from the Stata command line. With LD_LIBRARY_PATH, I can't. I hope this helps someone out.

If you're on an OS that doesn't provide libpng12, like Ubuntu 18.04, you can place a copy of libpng12.so.0 in the stata-png-fix directory. This way, you don't have to install an outdated library system-wide. You'll then also need to run the "--set-rpath" command on stata/stata-mp/stata-se, though not the "--add-needed" command. (This is not necessary if your system provides libpng12.)

[Claudio Leite]

Sorry, those library paths should be $HOME/local/stata-png-fix/lib instead:

cd $HOME/local/stata
patchelf --set-rpath $HOME/local/stata-png-fix/lib xstata
patchelf --add-needed libpng16.so.16 xstata

[Josh Deutschmann]

Sorry, those library paths should be $HOME/local/stata-png-fix/lib instead:

cd $HOME/local/stata
patchelf --set-rpath $HOME/local/stata-png-fix/lib xstata
patchelf --add-needed libpng16.so.16 xstata

Claudio, thanks for sharing this! It worked perfectly for me, after manually following instructions above and installing zlib and libpng to ~/stata-png-fix. For Arch users, patchelf 0.9-1 is in the community repo.

[Pablo Cabrera]

Hi,

I also have issues installing Stata 14 in Ubuntu 18.04 LTS. My problem us also related to the library libpng. After installing I can normally access Stata from the console but I cannot open the GUI. The error message is:

libpng error: Libpng jmp_buf still allocated

I have tried different methods I have found here and in other webs:

a) Downloading and installing the old version of the libraries
b) Using the Stata integration master workaround
c) Using the Vilhuberl workaround

I have also tried to set the installation dir in /usr/local/stata14 as in the /home/local/stata14. Probably I'm missing something since I'm new to Linux and not an expert, but I would need a comprehensive woraround to solve this problem. Thanks.

[Blake Hamm]

I'm still having the problem with Stata15 on Ubuntu 18.04. It was working great on Ubuntu 16.04 and I didn't even need to do any work around.

Anyway, I've tried some of the techniques including Vilhuberl's: https://bitbucket.org/vilhuberl/stata-png-fix/overview . I also tried Claudio's recent update and still didn't have any luck.

I haven't noticed anyone with Stata15 and Ubuntu 18.04. Has anyone had luck with this?

SIDE VENT:
It's crazy to think this has been a problem for over 4 years. Really disappointing on Stata's end. You'd think with how pricey the product and given the clientele who likely use Linux OS, that they would accommodate. I guess Stata expects users with Linux OS to use Stata without a GUI, but I'm not ready for that yet..

Thanks in advance friends!

[Chinh Nguyen (StataCorp)]

I believe I've identified the source of the problem that was causing newer versions of libpng to fail in Stata. This will be addressed in an update. If you would like to test the fix, please contact [email protected] and ask for the libpng fix. You should indicate which version of Stata (14 or 15) and which flavor (Stata/IC, Stata/SE, or Stata/MP) you need.

libpng12 is still required for Stata to run but you should not need any other workarounds.

[Rob Hicks]

I've tried the patched version of Stata 15 mentioned in #25 on both Ubuntu and Fedora. All the icon problems are eliminated and furthermore third party stata packages like markstat that also rely on libpng (for pdf output) work fine. So it seems like the problem is fixed since it has been mainlined into Stata 16. Thanks to Stata for listening to the Linux user community.

[Yuji Shimohira]

Rob Hicks : did you contact them at the address mentioned in #25 or do you mean you updated your Stata 15 installation and the problems are gone? Just asking because I ran (again, for the 1000th time in the last 5 years) into the infamous libpng12 issue.

I have had a solution at hand for a long time now, but I was surprised to see that the newer versions of Ubuntu present yet a new problem when installing libpng12: the architecture of the /lib and /usr/lib directories has changed--so a bit of tinkering with the pkg is needed. All working and fine (I am on Stata 15 too), but I am curious to see if you got that fix from them directly over email correspondence.

I understand what Stata Corp. said last year about "older" and "newer" Linux-distro users but... come on, libpng12 was discarded a long time ago for good security reasons. Even a "conservative" distro like CentOS 7 uses a newer version of libpng.

[Jose Andres Jurado]

Unfortunately, unlike Stata itself, Linux libraries aren't always designed to be backward compatible. Stata uses GTK+ 2 for creating it's graphical user interface. Stata asks GTK+ 2 to load Stata's icons. GTK+ 2 uses libpng to read the icons and the version of libpng it wants to use must be installed. The version of GTK+ 2 Stata links against is using an older version of libpng which is causing the problem many of you have are encountering. We link against this older version of GTK+ 2 to support our users who are still running older linux distributions including many of our enterprise users who are unable to upgrade their linux distros.

The problem for us is this: switch to a newer version, and hear of problems from everyone with the older version; remain with the older version, and hear of problems from everyone with the newer version. Statically-linking a particular version can also be problematic. In the future we may simply provide multiple distributions for multiple 'ages' of Linux.

or you know, package this in a snap or flatpak ....

[larsvilhuber]

Replying to the old reply by Chinh:
I think many of us will understand the "support for old distros for paying customers" but I'm not sure they will in turn appreciate the security risks with this, and the antiquity of it all. A few thoughts:

Security:
- "libpng versions 1.6.36 and earlier have a use-after-free bug... CVE-2019-7317" - in my experience with corporate-like environments, just the fact that you are relying on a library released in June of 2013 is an issue. It has at least one, if not more CVE issues outstanding. On the systems I know, this would mean either "not being certified to operate" or an expensive "remediation ticket/process".

Distribution of old distros:
- I'm going to assume that distros released after Jan 1 2014 do not include libpng 1.6.2 anymore.
- Ubuntu 14.04 LTS - released April 2014 - EOL April 2019 - no corporate customers should be running this system anymore, since it is past EOL.
- RHEL 6 - released 2010 - EOL May 10 2016, end of Maintenance Support 1 May 10 2017, Product retirement Nov 30 2020. Note that RHEL6 used libpng 1.2, not 1.6.
- RHEL 7 - released 2014 (actually uses libpng 1.5) - EOL Aug 6 2019.
- RHEL 8 - May 2019 - uses libpng 1.6.34 > 1.6.2 - not a problem...

So I'm not entirely clear what the "legacy support" is actually supporting.

[Elliott Collins]

FYI, I'm on Ubuntu 19.04 trying to install Stata15. The stata-png-fix above worked, but Installing libpng12 required some looking since it's been removed in the most recent software repositories.
What finally worked was: https://askubuntu.com/questions/1136...cket-tracert-7
Which contains the link to: https://www.dropbox.com/s/79x3imq73t...amd64.deb?dl=0