Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Unable to build zlib 1.2.8 on Ubuntu 14.04

Ashwin_D_
Beginner
2,532 Views

Hello,

             I am trying to build zlib 1.2.8 with icc and icpc on Ubuntu 14.04. I get the following messages when I run ./configure --prefix=/usr/local/zlib1.2.8.

 

Then when I type make fails ld: cannot find -lstdc++. Any comments appreciated.

Regards,

Ashwin.

 

Checking for shared library support...
No shared library support; try without defining CC and CFLAGS
Building static library libz.a version 1.2.8 with icc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for strerror... No.
Checking for unistd.h... Yes.
Checking for stdarg.h... Yes.
Checking whether to use vsprintf() or sprintf()... using vsprintf().
Checking for vsnprintf() in stdio.h... No.
  WARNING: vsnprintf() not found, falling back to vsprintf(). zlib
  can build but will be open to possible buffer-overflow security
  vulnerabilities.
Checking for return value of vsprintf()... Yes.
Checking for attribute(visibility) support... Yes.
ind -lstdc++
(exit code 1)
No shared library support; try without defining CC and CFLAGS
Building static library libz.a version 1.2.8 with icc.

=== ztest3899.c ===
#include <sys/types.h>
off64_t dummy = 0;
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 ztest3899.c
Checking for off64_t... Yes.
Checking for fseeko... Yes.

=== ztest3899.c ===
#include <string.h>
#include <errno.h>
int main() { return strlen(strerror(errno)); }
===
icc -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -o ztest3899 ztest3899.c
ld: cannot find -lstdc++
(exit code 1)
Checking for strerror... No.

=== ztest3899.c ===
#include <unistd.h>
int main() { return 0; }
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR ztest3899.c
Checking for unistd.h... Yes.

=== ztest3899.c ===
#include <stdarg.h>
int main() { return 0; }
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR ztest3899.c
Checking for stdarg.h... Yes.

=== ztest3899.c ===
#include <stdio.h>
#include <stdarg.h>
#include "zconf.h"
int main()
{
#ifndef STDC
  choke me
#endif
  return 0;
}
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR ztest3899.c
Checking whether to use vsprintf() or sprintf()... using vsprintf().

=== ztest3899.c ===
#include <stdio.h>
#include <stdarg.h>
int mytest(const char *fmt, ...)
{
  char buf[20];
  va_list ap;
  va_start(ap, fmt);
  vsnprintf(buf, sizeof(buf), fmt, ap);
  va_end(ap);
  return 0;
}
int main()
{
  return (mytest("Hello%d\n", 1));
}
===
icc -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -o ztest3899 ztest3899.c
ld: cannot find -lstdc++
(exit code 1)
Checking for vsnprintf() in stdio.h... No.
  WARNING: vsnprintf() not found, falling back to vsprintf(). zlib
  can build but will be open to possible buffer-overflow security
  vulnerabilities.

=== ztest3899.c ===
#include <stdio.h>
#include <stdarg.h>
int mytest(const char *fmt, ...)
{
  int n;
  char buf[20];
  va_list ap;
  va_start(ap, fmt);
  n = vsprintf(buf, fmt, ap);
  va_end(ap);
  return n;
}
int main()
{
  return (mytest("Hello%d\n", 1));
}
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf ztest3899.c
Checking for return value of vsprintf()... Yes.

=== ztest3899.c ===
#define ZLIB_INTERNAL __attribute__((visibility ("hidden")))
int ZLIB_INTERNAL foo;
int main()
{
  return 0;
}
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf ztest3899.c
Checking for attribute(visibility) support... Yes.

ALL = static all64
AR = ar
ARFLAGS = rc
CC = icc
CFLAGS = -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf -DHAVE_HIDDEN
CPP = icc -E
EXE =
LDCONFIG = ldconfig
LDFLAGS =
LDSHARED = icc
LDSHAREDLIBC = -lc
OBJC = $(OBJZ) $(OBJG)
PIC_OBJC = $(PIC_OBJZ) $(PIC_OBJG)
RANLIB = ranlib
SFLAGS = -O3 -ip -D_LARGEFILE64_SOURCE=1 -fPIC -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf -DHAVE_HIDDEN
SHAREDLIB =
SHAREDLIBM =
SHAREDLIBV =
STATICLIB = libz.a
TEST = all teststatic test64
VER = 1.2.8
Z_U4 =
exec_prefix = ${prefix}
includedir = ${prefix}/include
libdir = ${exec_prefix}/lib
mandir = ${prefix}/share/man
prefix = /usr/local/zlib-1.2.8
sharedlibdir = ${libdir}
uname = Linux
--------------------


--------------------
./configure --prefix=/usr/local/zlib-1.2.8
Sun Aug 24 13:37:37 IST 2014
=== ztest4124.c ===
extern int getchar();
int hello() {return getchar();}
===
icc -c ztest4124.c
... using gcc

Checking for obsessive-compulsive compiler options...
=== ztest4124.c ===
int foo() { return 0; }
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 ztest4124.c

Checking for shared library support...
=== ztest4124.c ===
extern int getchar();
int hello() {return getchar();}
===
icc -w -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -fPIC ztest4124.c
icc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -O3 -ip -D_LARGEFILE64_SOURCE=1 -fPIC -o ztest4124.so ztest4124.o
ld: cannot find -lstdc++
(exit code 1)
No shared library support; try without defining CC and CFLAGS
Building static library libz.a version 1.2.8 with icc.

=== ztest4124.c ===
#include <sys/types.h>
off64_t dummy = 0;
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 ztest4124.c
Checking for off64_t... Yes.
Checking for fseeko... Yes.

=== ztest4124.c ===
#include <string.h>
#include <errno.h>
int main() { return strlen(strerror(errno)); }
===
icc -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -o ztest4124 ztest4124.c
ld: cannot find -lstdc++
(exit code 1)
Checking for strerror... No.

=== ztest4124.c ===
#include <unistd.h>
int main() { return 0; }
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR ztest4124.c
Checking for unistd.h... Yes.

=== ztest4124.c ===
#include <stdarg.h>
int main() { return 0; }
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR ztest4124.c
Checking for stdarg.h... Yes.

=== ztest4124.c ===
#include <stdio.h>
#include <stdarg.h>
#include "zconf.h"
int main()
{
#ifndef STDC
  choke me
#endif
  return 0;
}
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR ztest4124.c
Checking whether to use vsprintf() or sprintf()... using vsprintf().

=== ztest4124.c ===
#include <stdio.h>
#include <stdarg.h>
int mytest(const char *fmt, ...)
{
  char buf[20];
  va_list ap;
  va_start(ap, fmt);
  vsnprintf(buf, sizeof(buf), fmt, ap);
  va_end(ap);
  return 0;
}
int main()
{
  return (mytest("Hello%d\n", 1));
}
===
icc -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -o ztest4124 ztest4124.c
ld: cannot find -lstdc++
(exit code 1)
Checking for vsnprintf() in stdio.h... No.
  WARNING: vsnprintf() not found, falling back to vsprintf(). zlib
  can build but will be open to possible buffer-overflow security
  vulnerabilities.

=== ztest4124.c ===
#include <stdio.h>
#include <stdarg.h>
int mytest(const char *fmt, ...)
{
  int n;
  char buf[20];
  va_list ap;
  va_start(ap, fmt);
  n = vsprintf(buf, fmt, ap);
  va_end(ap);
  return n;
}
int main()
{
  return (mytest("Hello%d\n", 1));
}
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf ztest4124.c
Checking for return value of vsprintf()... Yes.

=== ztest4124.c ===
#define ZLIB_INTERNAL __attribute__((visibility ("hidden")))
int ZLIB_INTERNAL foo;
int main()
{
  return 0;
}
===
icc -c -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf ztest4124.c
Checking for attribute(visibility) support... Yes.

ALL = static all64
AR = ar
ARFLAGS = rc
CC = icc
CFLAGS = -O3 -ip -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf -DHAVE_HIDDEN
CPP = icc -E
EXE =
LDCONFIG = ldconfig
LDFLAGS =
LDSHARED = icc
LDSHAREDLIBC = -lc
OBJC = $(OBJZ) $(OBJG)
PIC_OBJC = $(PIC_OBJZ) $(PIC_OBJG)
RANLIB = ranlib
SFLAGS = -O3 -ip -D_LARGEFILE64_SOURCE=1 -fPIC -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf -DHAVE_HIDDEN
SHAREDLIB =
SHAREDLIBM =
SHAREDLIBV =
STATICLIB = libz.a
TEST = all teststatic test64
VER = 1.2.8
Z_U4 =
exec_prefix = ${prefix}
includedir = ${prefix}/include
libdir = ${exec_prefix}/lib
mandir = ${prefix}/share/man
prefix = /usr/local/zlib-1.2.8
sharedlibdir = ${libdir}
uname = Linux
--------------------

0 Kudos
7 Replies
TimP
Honored Contributor III
2,532 Views

Apparently, you are asking icc to link a C++ application.  icc and icpc mirror the distinction between gcc and g++, with only the C++ compiler having built-in ability to find C++ libraries.  The feature of over-riding selection of a C compiler by specifying a .CC or .cpp input file doesn't survive to the link stage.

You do need a fully functional g++ on path so that icpc can use libraries including libstdc++.

The comments make it appear that you specified something like CC = icc without equivalent C++ define, such as CXX = icpc.  I suppose the suggestion of dropping CC may cause it to choose gcc and g++, which would be OK.  There isn't necessarily any advantage to use of icpc for such an application, as the libraries built by g++ must work with icpc as well.

0 Kudos
Sukruth_H_Intel
Employee
2,532 Views

Apart from whatever Tim pointed out, I am also guessing that this is an issue with *NON-AVAILABILITY* of static libc? because i see these messages :-
Checking for shared library support...

No shared library support; try without defining CC and CFLAGS

 

Since there are no shared libs support, its switching to use static libs.

So you may also give a try by installing the static libc and including the path in library path and build again.

Regards,

Sukruth H V

 

0 Kudos
Ashwin_D_
Beginner
2,532 Views

Hello Tim and Sukruth,

                                      Many thanks for your prompt response. I did what Tim told me . I set on my BASH shell export CXX=icpc and then proceeded to type ./configure --prefix=/usr/local/

 

and then I see the script runs just fine. However it runs the gcc version of the code. I presume that is OK because I have a long way ahead. I need to build HDF5, then NetCDF4, NetCDF-fortran, Jasper, PNG, WRF(Weather Research Forecasting), WPS and then finally WRFDA. Any mistake at this stage would be very costly exercise later on. If by setting CXX=icpc gcc compiles zlib pray may I ask did I do the do right thing by installing icc and icpc ? Because what I really want is to compile WRF with icc and ifort and NOT gcc and gfortran

Sukruth - I do not know how to install static libc. Please guide me accordingly or provide a URL.

Please advise me accordingly.

 

Regards,

Ashwin.

 

0 Kudos
Sukruth_H_Intel
Employee
2,532 Views

Hi Ashwin,

                  Sukruth - I do not know how to install static libc. Please guide me accordingly or provide a URL.

Sorry i had missed to provide a link to the article describing the workarounds, Please refer to this doc :-

https://software.intel.com/en-us/articles/error-ld-cannot-find-lm/ ;

However if you are using Ubuntu, then you may try this command to install the libs :- "apt-get install build-essential"

Regards,

Sukruth H V

0 Kudos
Ashwin_D_
Beginner
2,532 Views

Hi Sukruth,

                  That works just fine i.e. the ubuntu update. But it is still using gcc to build zlib. Is that OK ? I tried to build JASPER by setting export CC=icc. Again got a whole bunch of configure errors. I want to be clear one more time. My goal is to build WRF and WPS and WRFDA with icc and ifort NOT gcc and gfortran. Why ? Because I have some NETCDF errors with gfortran I am unable to fix.

 

So it is absolutely crucial that I build with icc and ifort. If we are going to do this route of mixed libraries i.e. compiling some with gcc and some others with icc and ifort I hope things will turn out OK in the end.

 

Regards,

Ashwin.

0 Kudos
Ashwin_D_
Beginner
2,532 Views

I am trying to use the same thread to my total build errors. Please let me know if I need to open a separate thread for every library that I am building.

 

This is with libpng and setting CC=icc.

 

This is the log that I have when I type make.

 

libtool: link: icc -g -O2 -o .libs/pngfix contrib/tools/pngfix.o  ./.libs/libpng16.so -lm -lz
ld: warning: libimf.so, needed by ./.libs/libpng16.so, not found (try using -rpath or -rpath-link)
ld: warning: libsvml.so, needed by ./.libs/libpng16.so, not found (try using -rpath or -rpath-link)
ld: warning: libirng.so, needed by ./.libs/libpng16.so, not found (try using -rpath or -rpath-link)
ld: warning: libintlc.so.5, needed by ./.libs/libpng16.so, not found (try using -rpath or -rpath-link)
ld: .libs/pngfix: hidden symbol `__intel_cpu_feature_indicator' in /opt/intel/composer_xe_2013_sp1.3.174/compiler/lib/intel64/libirc.a(cpu_feature_disp.o) is referenced by DSO
ld: final link failed: Bad value
make[1]: *** [pngfix] Error 1
make[1]: Leaving directory `/home/aswin/meteorology_project/libpng-1.6.12'
make: *** [all] Error 2

 

0 Kudos
TimP
Honored Contributor III
2,532 Views

If that build script uses the typical scheme of CC and CXX to choose C and C++ compilers, you should be able to set CC=icc CXX=icpc

The link errors would be caused by building objects with icpc but then attempting to use g++ to link, as g++ and ld themselves aren't aware of the libraries provided with icpc.

0 Kudos
Reply