undefined reference to `compress2'

[ArchRobison]

I did a fresh clone this afternoon, and got three undefined references. Here's an excerpt from the build:

    LINK usr/bin/julia-readline
/localdisk/adrobiso/dev2/julia/usr/lib/libjulia.so: undefined reference to `compress2'
/localdisk/adrobiso/dev2/julia/usr/lib/libjulia.so: undefined reference to `compressBound'
/localdisk/adrobiso/dev2/julia/usr/lib/libjulia.so: undefined reference to `uncompress'
collect2: error: ld returned 1 exit status
*** Please ensure that the ncurses-devel package is installed on your OS, and try again. ***
make[2]: *** [/localdisk/adrobiso/dev2/julia/usr/bin/julia-readline] Error 1

When I last did a fresh clone a few weeks ago, I wasn't having this problem. Any suggestions on how to fix it? It looks like "-lz" is required on the link line.

[ViralBShah]

Since LLVM expects to link with libz, so does libjulia. Do you have the zlib-devel or equivalent package for your OS installed?

It may very well be that -lz is required, but I just built a fresh copy and went through fine on mac. Perhaps someone else on linux can verify?

[ArchRobison]

I thought that the Julia build system automatically downloaded zlib and compiled it. But zlib is conspicuously absent from my deps/ directory. Also in deps/Makefile, I see a dependence commented out:

#ifeq ($(USE_SYSTEM_ZLIB), 0)
#STAGE1_DEPS += zlib
#endif

I also see that julia/Makefile has some logic commented out:

#ifeq ($(USE_SYSTEM_ZLIB),0)
#JL_PRIVATE_LIBS += z
#endif

I tried uncommenting all the lines above but I'm still getting the unresolved symbols, but maybe I have some stale state. I'm rebuilding after a distclean now.

Is the commenting out of the code an indication that zlib is expected to be supplied separately?

[kmsquire]

In v0.1, zlib was included specifically for reading and writing gzip
files. This was later split out into ZLib and GZip packages, and the
download for zlib was removed from deps.

Kevin

On Wed, Nov 6, 2013 at 2:46 PM, ArchRobison notifications@github.comwrote:

I thought that the Julia build system automatically downloaded zlib and
compiled it. But zlib is conspicuously absent from my deps/ directory.
Also in deps/Makefile, I see a dependence commented out:

#ifeq ($(USE_SYSTEM_ZLIB), 0)
#STAGE1_DEPS += zlib
#endif

I also see that julia/Makefile has some logic commented out:

#ifeq ($(USE_SYSTEM_ZLIB),0)
#JL_PRIVATE_LIBS += z
#endif

I tried uncommenting all the lines above but I'm still getting the
unresolved symbols, but maybe I have some stale state. I'm rebuilding after
a distclean now.

Is the commenting out of the code an indication that zlib is expected to
be supplied separately?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4742#issuecomment-27921807
.

[staticfloat]

@kmsquire so should we remove everything about zlib from deps/Makefile? I was somewhat surprised to see we still have quite a bit of machinery to download/compile zlib on various platforms.

Also, @vtjnash or @loladiro do you know if zlib is downloaded/built in this manner for our windows distributions?

[ArchRobison]

Thanks for the replies. From where should I get the ZLib package?

I see now why the commented-out code won't work anyway: the -lz ends up on the link line after the -ljulia. The latter needs the symbol from the former, so libz.a is searched too early. (I'm on Linux.)

[kmsquire]

The ZLib package would be installed after you compile julia, so it won't
help with your current issue.

What flavor of Linux are you on? Your best bet is to install zlib-dev or
zlib-devel through your package manager or whatever tool is used to install
things on your system.

Kevin

On Wed, Nov 6, 2013 at 3:22 PM, ArchRobison notifications@github.comwrote:

Thanks for the replies. From where should I get the ZLib package?

I see now why the commented-out code won't work anyway: the -lz ends up
on the link line after the -ljulia. The latter needs the symbol from the
former, so libz.a is searched too early. (I'm on Linux.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4742#issuecomment-27924236
.

[kmsquire]

@staticfloat, I wasn't aware of the LLVM requirement for zlib until this issue came up. Before that, I was under the impression that all of zlib was removed, so we should either

1. remove it all (which shouldn't change the current build process at all), or
2. fix it so that LLVM can use it to build when it's not installed.

Since libLLVM-3.3.so definitely needs to link against it, 2) would probably be worthwhile.

[vtjnash]

On windows I download zlib.dll as a separate, completely independent step (during install). The windows llvm has no dependency on zlib (since it detects that it is not available).

[ViralBShah]

We should probably remove the zlib build machinery. I had left it in there for cases such as this one, where one may want to get it manually, if they do not have root permissions.

[ViralBShah]

We should probably remove the zlib build machinery. I had left it in there for cases such as this one, where one may want to get it manually, if they do not have root permissions.

[ArchRobison]

I would be inclined to remove the zlib build machinery since it's commented out and therefore not being tested on a regular basis.

The root problem turned out to not be that zlib was missing. It's that the linker flags are in the wrong order. I'm on Ubuntu 12.0 Linux. The GNU linker inherited the annoying feature of Unix's ld that "-lx -ly" will let liby resolve symbols in libx, but not vice-versa. This patch fixes the problem by swapping the last two command-line arguments to become: -ljulia $(JLDFLAGS) If that looks like the right fix, I'll submit a formal pull request.

[staticfloat]

@ArchRobison that patch seems reasonable enough. I know we've had mystery errors like this pop up from time to time regarding linker command order. Why don't you go ahead and submit a pull request and I'll ping the people who might care about this change.