ERROR : (.text+0x3d): undefined reference to `apr_initialize'
Dear
I am working in Linux SUSE environment .
I am new to APR . I have made the sample program in C (gcc) using APR
library .
Every Time I run the program this error occurs :
ERROR : (.text+0x3d): undefined reference to `apr_initialize'
I have checked the paths for the apr include and lib folders . They are
correct.
The sample program is given below.
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include stdio.h
#include stdlib.h
#include assert.h
#include apr_general.h
#include apr_pools.h
#define MEM_ALLOC_SIZE 1024
int main(int argc, const char *argv[])
{
system(clear);
printf(\n\n\t\t\t\t\t\tIN MAIN\n\n);
apr_status_t rv;
apr_pool_t *mp;
char *buf1;
char *buf2;
// per-process initialization //
rv = apr_initialize();
//rv = apr_app_initialize(argc,argv,NULL);
if (rv != APR_SUCCESS) {
assert(0);
return -1;
}
// create a memory pool. //
apr_pool_create(mp, NULL);
// allocate memory chunks from the memory pool //
buf1 = apr_palloc(mp, MEM_ALLOC_SIZE);
buf2 = apr_palloc(mp, MEM_ALLOC_SIZE);
// destroy the memory pool. These chunks above are freed by this //
apr_pool_destroy(mp);
apr_terminate();
printf(\n\n\t\t\t\t\t\tSUCCESSFUL\n\n);
return 0;
}
-
The complete error information is given below:
-
gcc -c -I/usr/local/include/subversion-1 -I/usr/local/apr/include/apr-0 test.c
-o test.o -L/usr/local/lib -L/usr/local/apr/lib
gcc -o test test.o -L/usr/local/lib -L/usr/local/apr/lib
test.o: In function `main':
test.c:(.text+0x3d): undefined reference to `apr_initialize'
collect2: ld returned 1 exit status
make: *** [all] Error 1
The make file is given below :
---
INC=-I/usr/local/include/subversion-1 -I/usr/local/apr/include/apr-0
LIB=-L/usr/local/lib -L/usr/local/apr/lib
all:
gcc -c $(INC) test.c -o test.o $(LIB)
gcc -o test test.o $(LIB)
./test
clean:
rm -f test.o
kindly reply me as soon as possible . I shall be grateful to you for this act
of kindness.
Regards,
Hassan Shabbir
Re: ERROR : (.text+0x3d): undefined reference to `apr_initialize'
Quoting ISF - Hassan Shabbir [EMAIL PROTECTED]: gcc -o test test.o $(LIB) Have you tried with -lapr-0 -laprutil-0 (or similar) at the end of the above? -- Bojan
Re: [PATCH]: Introduce apr_dbd_transaction_rollback
On Friday 28 April 2006 05:57, Bojan Smojver wrote: This was never compiled, let alone tested. It is here as a prototype for Ronen's suggestion. Hmmm. Not too keen on this. The original logic of APR end transaction is that it'll commit a successful transaction otr rollback one where an error occurred. What's missing is the option to rollback even when successful. In principle, a rollback argument to transaction_end would be a better way to accomplish this. What level of version bump would we need to introduce that? -- Nick Kew
Re: ERROR : (.text+0x3d): undefined reference to `apr_initialize'
On Friday 28 April 2006 08:22, Bojan Smojver wrote: Quoting ISF - Hassan Shabbir [EMAIL PROTECTED]: gcc -o test test.o $(LIB) You forgot to link the libraries! Have you tried with -lapr-0 -laprutil-0 (or similar) at the end of the above? ITYM apr-1 :-) Which reminds me: what's the function of the numeric suffix? I keep forgetting that and finding myself with -lapr -laprutil in a makefile. -- Nick Kew
Re: [PATCH]: Introduce apr_dbd_transaction_rollback
On Fri, 2006-04-28 at 10:31 +0100, Nick Kew wrote: What's missing is the option to rollback even when successful. In principle, a rollback argument to transaction_end would be a better way to accomplish this. What level of version bump would we need to introduce that? Given that this would break binary compatibility, it would have to be done in 2.x. The new function approach could be done for 1.3. -- Bojan
Re: ERROR : (.text+0x3d): undefined reference to `apr_initialize'
On Fri, 2006-04-28 at 10:41 +0100, Nick Kew wrote: Which reminds me: what's the function of the numeric suffix? Probably to be able to have multiple binary incompatible major versions installed in parallel. -- Bojan
Re: [PATCH]: Introduce apr_dbd_transaction_rollback
Bojan: On Fri, 2006-04-28 at 10:31 +0100, Nick Kew wrote: What's missing is the option to rollback even when successful. In principle, a rollback argument to transaction_end would be a better way to accomplish this. What level of version bump would we need to introduce that? Given that this would break binary compatibility, it would have to be done in 2.x. The new function approach could be done for 1.3. This is great either way -- it's been on my to-do list but I've had to keep punting on it. Delighted to see something disappear off the list! As a not-committer, I don't really have a say here, but either option seems fine to me in terms of functionality (obviously). My gut instinct would be that I prefer the rollback argument Nick suggests purely for elegance, and that since apr_dbd is relatively new, breaking binary compatibility (so long as it's done with the appropriate version bumps) in the name of a clean interface isn't too horrible. Now I'm partly assuming that there can't be zillions of users yet relying on it in a 1.3 environment who really also need a forceable rollback feature, and that those who do can upgrade to 2.x. (After all, isn't it good to provide these little inducements to encourage folks to upgrade? :-) Whatever is chosen, kudos for dealing with this. Thanks! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [PATCH]: Introduce apr_dbd_transaction_rollback
In my opinion two separate functions, one for commit and one for rollback will be better and produce more readable code for the application. I am not aware of a single DB API out there that combines these two operations into one function. This does not mean it does not exist of-course, however it does suggest that using one function is somewhat unusual and probably undesirable. Nick Kew wrote: On Friday 28 April 2006 05:57, Bojan Smojver wrote: This was never compiled, let alone tested. It is here as a prototype for Ronen's suggestion. Hmmm. Not too keen on this. The original logic of APR end transaction is that it'll commit a successful transaction otr rollback one where an error occurred. What's missing is the option to rollback even when successful. In principle, a rollback argument to transaction_end would be a better way to accomplish this. What level of version bump would we need to introduce that?
Re: [PATCH]: Introduce apr_dbd_transaction_rollback
To add to that, the logic of ANY commit operation not just APR's end_transaction() is to commit a successful transaciton and rollback if an error occurs. This is what commit does by definition and it has nothing to do with an applicative decision to rollback the transaction which happens in case of an applicative error and not database error. Ronen Mizrahi wrote: In my opinion two separate functions, one for commit and one for rollback will be better and produce more readable code for the application. I am not aware of a single DB API out there that combines these two operations into one function. This does not mean it does not exist of-course, however it does suggest that using one function is somewhat unusual and probably undesirable. Nick Kew wrote: On Friday 28 April 2006 05:57, Bojan Smojver wrote: This was never compiled, let alone tested. It is here as a prototype for Ronen's suggestion. Hmmm. Not too keen on this. The original logic of APR end transaction is that it'll commit a successful transaction otr rollback one where an error occurred. What's missing is the option to rollback even when successful. In principle, a rollback argument to transaction_end would be a better way to accomplish this. What level of version bump would we need to introduce that?
Re: [PATCH]: Introduce apr_dbd_transaction_rollback
On Fri, 2006-04-28 at 09:41 -0400, Chris Darroch wrote: Now I'm partly assuming that there can't be zillions of users yet relying on it in a 1.3 environment who really also need a forceable rollback feature, and that those who do can upgrade to 2.x. (After all, isn't it good to provide these little inducements to encourage folks to upgrade? :-) By far the most important piece of software that uses APR 1.2.x is Apache 2.2 and associated modules. An upgrade of APR to 2.x there would most likely require an MMN bump. I'm not sure if Apache development policies permit this any more mid minor version. However, using APR 1.3.x, given it is binary compatible with 1.2.x, would probably be an option. So, the upgrade here is all about timing, AFAIK. It would be good if Apache developers could enlighten us a bit more here... -- Bojan
Re: [PATCH] apr_thread_yield with pthread
William A. Rowe, Jr. wrote: This has been sitting out a while. Any comments from the vocal majority on their favorite platform? Seems sane to me, but needs eyes from folks intimately familiar with the pthreads implementation. I noticed more are trying to purge the bug queue so thought it's a good time to mention again. +1 on Solaris 11. Cheers, Henry Bill Original Message Subject: [PATCH] apr_thread_yield with pthread Date: Mon, 27 Feb 2006 17:19:45 +0900 From: Keisuke Nishida [EMAIL PROTECTED] To: dev@apr.apache.org Hi, I'm new to APR. I've started using apr-1.2.2 as well as the trunk. I found the definition of apr_thread_yield is empty in apr/threadproc/unix/thread.c. Is there any reason why not to call pthread_yield or sched_yield? The attached patch does what I want. Best regards, Keisuke Nishida
Re: Makefile.in does not take external LIBS LDFLAGS
Here is the new patch.Cheers,HenryOn 4/9/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Henry Jen wrote: will not have the -R flag in the Makefile.Your patch is invalid because we need to proxy the whole accumulated LDFLAGS off to the client who's trying to compile against apr[-util].Fixing Makefile isn't enough, LDFLAGS must be 'sticky' within theaccumulated apr-1-config/apu-1-config syntax.Please revisit your patch and determine where your desired flags are being dumped by autoconf, and I'd be happy to commit a patch thatensures those user-given flags percolate into our APRUTIL_LDFLAGSthroughout the configuration, as opposed to committing a bandaid.Yours, Bill Index: configure.in === --- configure.in (revision 398058) +++ configure.in (working copy) @@ -97,6 +97,10 @@ APR_ADDTO(CFLAGS, `$apr_config --cflags`) APR_ADDTO(CPPFLAGS, `$apr_config --cppflags`) +dnl carry user defined LDFLAGS +APR_ADDTO(APRUTIL_LDFLAGS, $LDFLAGS) +APR_ADDTO(APRUTIL_LIBS, $LIBS) + dnl dnl Find the APR-ICONV directory. dnl
Re: Patch for checking expat on Solaris
On 4/10/06, Henry Jen [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: Henry Jen wrote: +elif test -r $1/include/expat.h; then +dnl Expat 1.95.* installation (without libtool) +dnl Solaris +expat_include_dir=$1/include +expat_ldflags=-L$1/lib -R$1/lib +expat_libs=-lexpat Here's my essential problems with growing this cruft further :( -L and -R should be redundant, no?No, they are not. -L is for link time, -R for runtime. For the defaultlinker on Solaris, the -R is taking the value from -L as gnu ld. I meant to say Solaris default linker does not behave the same as GNU ld. -R is recommended practice on Solaris. crle or LD_LIBRARY_PATH can do the trick, but those practice are discouraged. Further, there's this lovely assumption that because we find an expat .h in X/include/ we infer without any testing whatsoever there is a ld in X/lib. These sorts of fragile assumptions *throughout* the build system (not singling out specifically your patch), e.g. the old uuid detection code, ongoing debates about lib64 (you assume $1/lib, how do you know X/include/ isn't X/lib64/'s?) Make me really hesitate to touch the code further without a real test-compile and test-link as the new uuid code performs (before bailing with 'I surrender!')Thank you for the feedback, I will redo the patch.IMHO, we should do AC_CHECK_LIB with the default LDFLAGS/CFLAGS appended by the value of --with-expat suffixed with /include|/liband then makesure those flags are passed into the result Makefiles.Depending on the .a or .la file is in the place and readable is not morecorrect, I would think. Even if we want to do that, should we check for .so rather than .la or .a? Because the .a or .la should not be necessaryif the libexpat.so is built correctly. Take the Solaris example, thereis no .la or .a, only .so exist in /usr/sfw/lib, and the link will succeed. Attached please find a new patch using AC_CHECK_LIB to find the correct library path. Cheers,Henry Index: build/apu-conf.m4 === --- build/apu-conf.m4 (revision 398058) +++ build/apu-conf.m4 (working copy) @@ -63,27 +63,24 @@ expat_ldflags=-L$1/lib expat_libs=-lexpat expat_libtool=$1/lib/libexpat.la - elif test -r $1/include/expat.h -a \ --r $1/lib/libexpat.la; then -dnl Expat 1.95.* installation (with libtool) -expat_include_dir=$1/include -expat_ldflags=-L$1/lib -expat_libs=-lexpat -expat_libtool=$1/lib/libexpat.la - elif test -r $1/include/expat.h -a \ --r $1/lib64/libexpat.la; then -dnl Expat 1.95.* installation on certain 64-bit platforms (with libtool) -expat_include_dir=$1/include -expat_ldflags=-L$1/lib64 -expat_libs=-lexpat -expat_libtool=$1/lib64/libexpat.la - elif test -r $1/include/expat.h -a \ --r $1/lib/libexpat.a; then -dnl Expat 1.95.* installation (without libtool) -dnl FreeBSD textproc/expat2 -expat_include_dir=$1/include -expat_ldflags=-L$1/lib -expat_libs=-lexpat + elif test -r $1/include/expat.h; then +old_ldflags=$LDFLAGS +old_cflags=$CFLAGS +for d in $1/lib $1/libdir ; do + CFLAGS=$old_cflags -I$1/include + LDFLAGS=$old_ldflags -L$d -R$d + AC_CHECK_LIB(expat, XML_ParserCreate, [ +expat_include_dir=$1/include +expat_libs=-lexpat +expat_ldflags=-L$d -R$d +if test -r $d/libexpat.la; then + expat_libtool=$d/libexpat.la +fi +break + ], []) +done +CFLAGS=$old_cflags +LDFLAGS=$old_ldflags elif test -r $1/xmlparse.h; then dnl maybe an expat-lite. use this dir for both includes and libs expat_include_dir=$1 Index: build/dbd.m4 === --- build/dbd.m4 (revision 398058) +++ build/dbd.m4 (working copy) @@ -133,12 +133,12 @@ apu_have_sqlite3=0 else CPPFLAGS=-I$withval/include - LDFLAGS=-L$withval/lib + LDFLAGS=-L$withval/lib -R$withval/lib AC_MSG_NOTICE(checking for sqlite3 in $withval) AC_CHECK_HEADER(sqlite3.h, AC_CHECK_LIB(sqlite3, sqlite3_open, [apu_have_sqlite3=1])) if test $apu_have_sqlite3 != 0; then -APR_ADDTO(APRUTIL_LDFLAGS, [-L$withval/lib]) +APR_ADDTO(APRUTIL_LDFLAGS, [-L$withval/lib -R$withval/lib]) APR_ADDTO(APRUTIL_INCLUDES, [-I$withval/include]) fi fi
Re: Patch for checking expat on Solaris
Henry Jen wrote: -L and -R should be redundant, no? No, they are not. -L is for link time, -R for runtime. For the default linker on Solaris, the -R is taking the value from -L as gnu ld. I meant to say Solaris default linker does not behave the same as GNU ld. -R is recommended practice on Solaris. crle or LD_LIBRARY_PATH can do the trick, but those practice are discouraged. The issue I have is that your -enforcing- -R destroys my -portability-. We need to find a happy comprimize to build to a manditory -prefix versus the usual -prefix, yet relocatable (with LD_LIBRARY_PATH).
