apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Problem creating statically linked executable with APR
Date Mon, 13 Jun 2005 20:12:57 GMT
Nicholas;

  don't use libapr - that refers to 0.9.x and you will undoubtedly
create headaches.  Retain libapr-1 if that's the version you mean
to build against.

  Use apr-config-1 to query apr for the paths to the library, compile
time variables, etc.

  And it appears you might be missing -lc, which you would get by
querying apr-util for the link flags.

Bill

At 10:08 AM 6/13/2005, Nicholas Merryman wrote:

>Before I integrated APR functionality into this program, I could create the static executable
with no problems.  Below are my compile options / output.  I simply renamed libapr-1.a to
libapr.a and moved it to /linus/luz/lib, where all the other static libraries for my project
reside. Using the dynamic libapr, everything works fine, but I have a specific need for this
static executable. 
>
>
>g++ -c -o/linus/luz/obj/client/collectall/collectall.o -O1 -fPIC -W -Wall -Wno-unused
-DFDR_OS_LINUX -DFDR_OS_FLAVOR_REDHAT -DFDR_OS_VERSION=73 -DFDR_HARDWARE_IX86   -DFDR_PLATFORM_LINUX_GENERIC_GNU
-DFDR_PLATFORM_LUZ -DPLATFORM_COMPONENT_NAME=\"collectall\"  -I /linus/src/fdr/include/public
-I /linus/src/fdr/include/private -I /linus/src/fdr/include -I /linus/src/fdr/include/private/linux
-I /linus/src/fdr/include/private/gcc  collectall.cpp 
>
>g++ -static -O1 -fPIC -W -Wall -Wno-unused -DFDR_OS_LINUX -DFDR_OS_FLAVOR_REDHAT -DFDR_OS_VERSION=73
-DFDR_HARDWARE_IX86 -o /linus/luz/bin/collectall /linus/luz/obj/client/collectall/collectall.o
/linus/luz/lib/libfdrcore.a /linus/luz/lib/libxml.pi.a /linus/luz/lib/libreport.pi.a /linus/luz/lib/libzlib.a
/linus/luz/lib/libapr.a  -lz -lpthread -ldl -Xlinker -rpath-link -Xlinker /linus/luz/lib -L/linus/luz/lib

>/linus/luz/lib/libapr.a(dso.o)(.text+0x91): In function `apr_dso_load': 
>dso/unix/dso.c:138: Using 'dlopen' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking 
>/linus/luz/lib/libapr.a(groupinfo.o)(.text+0x24): In function `apr_gid_name_get': 
>user/unix/groupinfo.c:39: Using 'getgrgid_r' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking 
>/linus/luz/lib/libapr.a(groupinfo.o)(.text+0x78): In function `apr_gid_get': 
>user/unix/groupinfo.c:58: Using 'getgrnam_r' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking 
>/linus/luz/lib/libapr.a(userinfo.o)(.text+0x19): In function `getpwnam_safe': 
>user/unix/userinfo.c:41: Using 'getpwnam_r' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking 
>/linus/luz/lib/libapr.a(userinfo.o)(.text+0x100): In function `apr_uid_name_get': 
>user/unix/userinfo.c:117: Using 'getpwuid_r' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking 
>/linus/luz/lib/libapr.a(sockaddr.o)(.text+0x476): In function `call_resolver': 
>network_io/unix/sockaddr.c:336: Using 'getaddrinfo' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking 
>/linus/luz/lib/libapr.a(sockaddr.o)(.text+0x7d7): In function `apr_getservbyname': 
>network_io/unix/sockaddr.c:701: Using 'getservbyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking 
>
>
>Any ideas how can I resolve this? 
>
>Thanks, 
>Nick 



Mime
View raw message