Linker errors in a basic Apache module - c

I am attempting to write a "hello world" module for Apache HTTPD 2.4. I'm receiving some linker errors when building the module, and many Google searches have not revealed a solution.
My questions are:
How can I resolve the ap_hook_handler linker error? I've searched through the Apache Portable Runtime source and headers and have not found it.
Why is there an undefined reference to main? I thought shared objects don't have a main() entry point.
The source code:
// Dependancies: apr-devel apr-util-devel
#include <httpd.h>
#include <http_config.h>
#include <apr_hooks.h>
static int test_handler(request_rec* request)
{
return OK;
}
static void register_hooks(apr_pool_t *pool)
{
ap_hook_handler(test_handler, NULL, NULL, APR_HOOK_LAST);
}
module AP_MODULE_DECLARE_DATA test_module =
{
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
NULL,
register_hooks
};
The build command:
apxs -lapr-1 -laprutil-1 -c test.c -o mod_test.so
The errors:
apxs -lapr-1 -laprutil-1 -c test.c -o mod_test.so
/usr/lib64/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wformat-security -fno-strict-aliasing -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/httpd -I/usr/include/apr-1 -I/usr/include/apr-1 -c -o test.lo test.c && touch test.slo
/usr/lib64/apr-1/build/libtool --silent --mode=link gcc -o test.la -lapr-1 -laprutil-1 -rpath /usr/lib64/httpd/modules -module -avoid-version test.lo -o mod_test.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
.libs/test.o: In function `register_hooks':
/root/test/test.c:14: undefined reference to `ap_hook_handler'
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536

The order matters and the filenames have to go last:
apxs -c -o mod_test.so test.c
To install it automatically:
apxs -i -c -o mod_test.so -c test.c
This should work

As Ctx said, the order of parameters really matters. I use the following format of the APXS:
$APACHE/bin/apxs -c -a -i mod_test.c
what compiles, adds and installs the test module. It produces this output:
/usr/local/apr/build-1/libtool --silent --mode=compile gcc -prefer-pic -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -pthread -I$APACHE_HOME/include -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 -c -o mod_test.lo mod_test.c && touch mod_test.slo
/usr/local/apr/build-1/libtool --silent --mode=link gcc -o mod_test.la -rpath $APACHE_HOME/modules -module -avoid-version mod_test.lo
ar: `u' modifier ignored since `D' is the default (see `U')
$APACHE_HOME/build/instdso.sh SH_LIBTOOL='/usr/local/apr/build-1/libtool' mod_test.la $APACHE_HOME/modules
/usr/local/apr/build-1/libtool --mode=install install mod_test.la $APACHE_HOME/modules/
libtool: install: install .libs/mod_test.so $APACHE_HOME/modules/mod_test.so
libtool: install: install .libs/mod_test.lai $APACHE_HOME/modules/mod_test.la
libtool: install: install .libs/mod_test.a $APACHE_HOME/modules/mod_test.a
libtool: install: chmod 644 $APACHE_HOME/modules/mod_test.a
libtool: install: ranlib $APACHE_HOME/modules/mod_test.a
libtool: finish:
----------------------------------------------------------------------
Libraries have been installed in:
$APACHE_HOME/modules
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 $APACHE_HOME/modules/mod_test.so
[activating module `test' in $APACHE_HOME/conf/httpd.conf]
By providing the -o option you can get rid of undefined reference to main error message.

Related

how do I build a static shared library(self-sustain) using musl?

For some reasons, I want to build a static shared library: a self sustain
library that without any external dependent library.
My build environment is alpine linux.
(I believe that gcc is /usr/bin/aarch64-alpine-linux-musl-gcc)
I build my shared library as follows:
gcc -fpic -c jpg_to_bmp.c -o jpg_to_bmp.o
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
gcc -I ./ -L ./ main.c -o main.o
However
LD_LIBRARY_PATH=`pwd` ./main test.jpg test.bmp
dies with Segmentation fault
if I link the shared library without -static -lc -lstdc++
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
Everything works fine.
How do I build a static shared library(self-sustain) using musl ?
Did I miss any step or flag ?

GCC undefined reference to `addition'

I'm trying to link an external library but not linking. Using gcc version:
gcc (MinGW.org GCC Build-2) 9.2.0
Windows 10
Command I'm tried:
gcc -g test.c -Wall -I ../inc/ -L ../lib -l:libFp.a -o test.exe
gcc -g test.c -Wall -I ../inc/ -L ../lib64 -l:libFp.a -o test.exe
gcc -g -Wall -I ../inc/ -L ../lib -l:libFp.a test.c -o test.exe
gcc -g -Wall ../lib/libFp.a test.c -I ../inc/ -o test.exe
Error:
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\XXXXXXXX\AppData\Local\Temp\cciWnORn.o: in function `main':
D:\C_Training\utils\XXXXXXXX\testApp/test.c:35: undefined reference to `addition'
collect2.exe: error: ld returned 1 exit status
Folder Hierarchy:
XXXX
==docs
==inc
==lib
--libFp.a
--fP.lib
==lib64
--libFp.a
==src
==testApp [cwd]
--test.c
Tried different solutions from StackOverflow but still same error.
Update: gcc -g -Wall -I ../inc -L ../lib test.c -o test.exe -lFp -Xlinker --verbose command output
Linker Output Verbose

Building a C application against an external library on linux

I'm working on a Linux project in C consisting of two different open source applications. "Project A" (libduo) creates an archive used for linking a couple test programs and creates the library like this:
/usr/bin/ar rv libduo.a duo.o http_parser.o https.o match.o parson.o urlenc.o
/usr/bin/ar: creating libduo.a
a - duo.o
a - http_parser.o
a - https.o
a - match.o
a - parson.o
a - urlenc.o
ranlib libduo.a
One of the libduo test programs is built like this:
gcc -g -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -I. -I. -DDUODIR=\"/usr/local/duo/libduo/etc\" -DHAVE_CONFIG_H -c test-duologin.c
gcc -o test-duologin test-duologin.o -L. -lduo -lssl -lcrypto
"Project B" is an OpenLDAP module which I've built with -lduo and a few options to tell it where to find things:
(cd .libs && rm -f pw-apr1.la && ln -s ../pw-apr1.la pw-apr1.la)
../../../libtool --mode=compile gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -fPIC -DPIC -o .libs/pw-duo.o
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -o pw-duo.o >/dev/null 2>&1
../../../libtool --mode=link gcc -g -O2 -Wall -version-info 0:0:0 \
-rpath /usr/local/libexec/openldap -module -o pw-duo.la pw-duo.lo libduo.a -lduo
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
cc -shared .libs/pw-duo.o libduo.a -lduo -Wl,-soname -Wl,pw-duo.so.0 -o .libs/pw-duo.so.0.0.0
/usr/bin/ld: libduo.a(duo.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
libduo.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:51: recipe for target 'pw-duo.la' failed
make: *** [pw-duo.la] Error 1
The Makefile I'm using is the same one distributed with the OpenLDAP project. I've just added a section in the Makefile to build my module, using the same options for the other modules already there but adding -lduo to my section along with the paths to the libduo includes and libduo.a.
As make suggests above, I've recompiled by adding -fPIC after the -Wall option but it the same error was repeated. As a last resort, I tried adding -static to the module build but make was having none of that either:
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
This is the first time I've tried to build a C application against a lib not in the standard Linux locations so not exactly sure what's going on. I suspect libduo is built intended to be statically linked into everything, but the OpenLDAP modules are designed to use shared libraries. Can anyone elucidate?
Update: with help of comments below and this link I created a shared library from the .o files and distributed/built against that.

ZooKeeper C binding installation

I am trying to install the C binding for ZooKeeper while ssh'ed to another computer using a build system: i386-pc-solaris2.11 (I don't know if that is important). Anyways, the computer I ssh'ed to is running a linux based OS.
I ran the following code in the command line:
cd ../zookeeper
cd src
cd c
./configure
make
The terminal inputs above were taken from the Apache website for setting up the C shell client. The error code I am getting is originates from the make:
libtool: link: ( cd ".libs" && rm -f "libzookeeper_mt.la" && ln -s
"../libzookeeper_mt.la" "libzookeeper_mt.la" )
gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -
D_POSIX_PTHREAD_SEMANTICS -Wall -Werror -g -O2 -D_GNU_SOURCE -MT cli.o
-MD -MP -MF .deps/cli.Tpo -c -o cli.o `test -f 'src/cli.c' || echo
'./'`src/cli.c
mv -f .deps/cli.Tpo .deps/cli.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Werror -g -O2 -
D_GNU_SOURCE -o cli_st cli.o libzookeeper_st.la
libtool: link: gcc -Wall -Werror -g -O2 -D_GNU_SOURCE -o .libs/cli_st
cli.o ./.libs/libzookeeper_st.so -lnsl -lsocket -lm -R/usr/local/lib
gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -
D_POSIX_PTHREAD_SEMANTICS -DTHREADED -g -O2 -D_GNU_SOURCE -MT cli_mt-
cli.o -MD -MP -MF .deps/cli_mt-cli.Tpo -c -o cli_mt-cli.o `test -f
'src/cli.c' || echo './'`src/cli.c
mv -f .deps/cli_mt-cli.Tpo .deps/cli_mt-cli.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -DTHREADED -g -O2 -
D_GNU_SOURCE -o cli_mt cli_mt-cli.o libzookeeper_mt.la
libtool: link: gcc -DTHREADED -g -O2 -D_GNU_SOURCE -o .libs/cli_mt
cli_mt-cli.o ./.libs/libzookeeper_mt.so -lnsl -lsocket -lm -lpthread -
R/usr/local/lib
Undefined first referenced
symbol in file
__ .sync_fetch_and_add ./.libs/libzookeeper_mt.so
ld: fatal: symbol referencing errors. No output written to .libs/cli_mt
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `cli_mt'
Current working directory
/workspace/kunalp/mysource/usr/src/kunalp/zookeeperC2/src/c
*** Error code 1
make: Fatal error: Command failed for target `all'
cli_mt:localhost:2181 does not work as the ZooKeeper library is not installed in /usr/local/lib . I do however have zookeeper working in the C client on my local computer, I just need it working on this system.
Please help, this is just the installation of zookeeper on a linux computer. I don't understand linux too well, nor do I understand the error code given to me from this makefile.
EDIT: I figured out that I do not have permissions to change the /usrs/local/lib directory on this server. I tried
distclean && ./configure --prefix=/workspace/kunalp/zookeeper/ --libdir=/workspace/kunalp/zookeeper/lib && make install
to relocate the library directory. This however did not fix the problem, giving me the following error:
/bin/sh ./libtool --tag=CC --mode=link gcc -DTHREADED -g -O2 -
D_GNU_SOURCE -o cli_mt cli_mt-cli.o libzookeeper_mt.la
libtool: link: gcc -DTHREADED -g -O2 -D_GNU_SOURCE -o .libs/cli_mt
cli_mt-cli.o ./.libs/libzookeeper_mt.so -lnsl -lsocket -lm -lpthread -
R/workspace/kunalp/zookeeper/lib
Undefined first referenced
symbol in file
__sync_fetch_and_add ./.libs/libzookeeper_mt.so
ld: fatal: symbol referencing errors. No output written to .libs/cli_mt
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `cli_mt'
Thanks
The Solaris compiler does not have __sync_fetch_and_add. To fix this I had to find an equivalent function in the Solaris compailer: atomic_add() and replace __sync_fetch_and_add with atomic_add() in mt_adaptor.c. This fixed my make command

link problems with zlib on Solaris sparc 64-bit

When trying to build zlib-1.2.5 (or the latest, 1.2.7) on a Solaris-10 sparc machine, I get:
Relevant env. vars:
export CFLAGS="-m64 -O4"
export CXXFLAGS="-m64 -O4"
export CC="cc"
export CXX="CC"
Output of building:
Checking for shared library support...
Building shared library libz.so.1.2.7 with cc.
Checking for off64_t... Yes.
....
Checking for stdarg.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Looking for a four-byte integer type... Found.
cc -m64 -O4 -D_LARGEFILE64_SOURCE=1 -I. -c -o example.o test/example.c
cc -m64 -O4 -D_LARGEFILE64_SOURCE=1 -c -o adler32.o adler32.c
.... stripped a few lines
cc -m64 -O4 -D_LARGEFILE64_SOURCE=1 -c -o gzwrite.o gzwrite.c
ar rc libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
cc -m64 -O4 -D_LARGEFILE64_SOURCE=1 -o example example.o -L. libz.a
.... stripped a few lines
cc -G -h libz.so.1 -m64 -O4 -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.7 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo -lc
ld: fatal: relocation error: R_SPARC_H44: file crc32.lo: symbol <unknown>: relocations based on the ABS44 coding model can not be used in building a shared object
make: *** [libz.so.1.2.7] Error 1
I found the answer by now: Use option -xcode=pic32

Resources