Re: Incorrect apt-util-1.pc using --with-expat=builtin
Hi Jeff, If nobody responds in the next couple of days, please open a bug for this at http://issues.apache.org/bugzilla/ so that your report isn't forgotten. Filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=56232. Thanks for the suggestion, Rhys
Incorrect apt-util-1.pc using --with-expat=builtin
I've noticed atop APR Utils 1.5.3 that when I configure using
--with-expat=builtin I see the following within the installed
${prefix}/lib/pkgconfig/apr-util-1.pc:
Libs: -L${libdir} -laprutil-${APRUTIL_MAJOR_VERSION}
/g/g10/ulerich1/Build/apr-util-1.5.3/xml/expat/libexpat.la
while I'd expect to see
Libs: -L${libdir} -laprutil-${APRUTIL_MAJOR_VERSION} -lexpat
as the former build directory isn't guaranteed to exist after the
installation and ${prefix}/lib/libexpat.la and friends are installed
correctly.
A workaround is manually stitching up the installed pkg-config file.
Thanks,
Rhys
Anyone seeing -g -O2 in apr-1.pc after installation of 1.4.5?
Hi all,
I just built and installed the public APR 1.4.5 tarball and noticed that the
apr-1.pc file contains
Cflags: -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -pthread -I${includedir}
with a -g -O2 that shouldn't be there.
My configure line was merely ./configure. The tail end of configure shows
Restore user-defined environment settings...
restoring CPPFLAGS to
setting EXTRA_CPPFLAGS to -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
restoring CFLAGS to
setting EXTRA_CFLAGS to -g -O2 -pthread
restoring LDFLAGS to
setting EXTRA_LDFLAGS to
restoring LIBS to
setting EXTRA_LIBS to -luuid -lrt -lcrypt -lpthread
restoring INCLUDES to
setting EXTRA_INCLUDES to
and apr.pc.in uses
Cflags: @EXTRA_CPPFLAGS@ @EXTRA_CFLAGS@ -I${includedir}
which definitely explains where the -g -O2 came from.
Has anyone else observed this problem? Easy workaround is to manually
remove the flags from the installed pkgconfig file.
Thanks,
Rhys
Re: [vote] release apr 1.3.9?
Votes open for 48 hours... +1 'make check' clean on Ubuntu 8.04 64-bit using both GCC 4.3.1 and Intel 10.1 compilers. - Rhys
Re: [VOTE] Release APR 1.3.7
Nick Critical question here: is this a regression, or does 1.3.6 show Nick the same? Yes, I see the same problem on 1.3.6. Bojan See if this works for you. Bojan's patch definitely improves the situation. testoc and testflock now run cleanly. On make check I now see: --8--- testoc : SUCCESS testpath: SUCCESS testpipe: |Programs failed: testall make[1]: *** [check] Error 141 make[1]: Leaving directory `/home/rhys/tmp/apr-1.3.7/test' make: *** [check] Error 2 --8--- testpipe fails in the same way on the 1.3.6 release with Intel compilers. This testpipe problem does not look like a 1.3.6 - 1.3.7 regression. I have checked this on Ubuntu 9.04 / 32-bit this morning with Intel icc 10.1. I still can't SSH into the 8.04 / 64-bit system. - Rhys
Re: [VOTE] Release APR 1.3.7
All tests pass on Ubuntu 8.04 / 64-bit with gcc 4.3.1. On the same Ubuntu 8.04 / 64-bit system with Intel 10.1 compilers I see this from make check: testflock : \tryread: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory -tryread: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory testoc : \occhild: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory Not sure what to make of these. ldd shows that all executables in test/ can find the dynamic libraries, including libimf.so, correctly. Also not sure if icc is officially fair game or not... - Rhys
Re: [VOTE] Release APR 1.3.7
Not sure what to make of these. ldd shows that all executables in test/ can find the dynamic libraries, including libimf.so, correctly. When you say that ldd is fine with the whole thing - do you have LD_LIBRARY_PATH set at all somewhere or not? BTW, where is your libimf.so? LD_LIBRARY_PATH is set in my environment. libimf.so is in a nonstandard directory present in LD_LIBRARY_PATH. ldd finds libimf.so because it is in my LD_LIBRARY_PATH. I'm aftraid I can't give more solid answers than these-- due to some recent LDAP updates at my university, tonight I cannot SSH into to the system that gave me problems, and I am flying out for six days tomorrow morning. I believe the problems are related to my environment. Can anyone else with Intel''s icc weigh in here? - Rhys
apr 1.3.6 incorrectly includes -g -O2 in 'pkg-config --cflags
Hi all, apr version 1.3.6 incorrectly includes -g -O2 in the output of 'pkg-config --cflags apr-1': -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -pthread -I/org/centers/pecos/LIBRARIES/APR/apr-1.3.6-intel-10.1.017/include/apr-1 A pkg-config package shouldn't be mucking with optimization and debugging flags. Generally, all of the entries from -DLINUX=2 through -O2 look suspect in that output. I'm not good enough with apr to know if they're required, however. An #if statement including LINUX appears in the installed apr_general.h. Neither _REENTRANT nor _GNU_SOURCE appears in any of the headers in the installation directory. These entries appear in pkg-config output because @EXTRA_CPPFLAGS@ and @EXTRA_CFLAGS@ are present in apr.pc.in. Thanks for your time, Rhys
Re: apr 1.3.6 incorrectly includes -g -O2 in 'pkg-config --cflags
How did you configure apr? My config.nice for a build using Intel compilers contains --8--- #! /bin/sh # # Created by configure CC=icc; export CC ./configure \ --prefix=/org/centers/pecos/LIBRARIES/APR/apr-1.3.6-intel-10.1.017 \ CC=icc \ CXX=icpc \ CXXFLAGS=-DMPICH_IGNORE_CXX_SEEK \ F77=ifort \ $@ --8--- For the GNU compilers I see the same pkg-config behavior and my config.nice contains: ---8--- #! /bin/sh # # Created by configure CC=gcc; export CC ./configure \ --prefix=/org/centers/pecos/LIBRARIES/APR/apr-1.3.6-gcc-4.3.1-ubuntu-amd64 \ CC=gcc \ CXX=g++ \ CXXFLAGS=-DMPICH_IGNORE_CXX_SEEK \ F77=gfortran \ $@ ---8--- I am using autoconf v2.61. I see the same behavior on a Ubuntu 8.04 and 9.04 system. Any other details I can provide? CFLAGS=-g -O0 -Wall -fstack-protector; export CFLAGS ./configure \ --prefix=/home/groups/devel/run/apache \ CFLAGS=-g -O0 -Wall -fstack-protector \ $@ What happens for you when you don't set CFLAGS prior to running ./configure? - Rhys
