On 8/9/07, Anil Gulecha anil.verve at gmail.com wrote:
Hi all,
I was trying to port libntp library that allows talking to
Creative(and other) mp3 players.. the source consists of the libraries
and a sample application.
I had the initial -Wall errors that I corrected and the library has
built fine. However, the sample app isnt building.
bash-3.00$ pwd
/tmp/libnjb-2.2.5
bash-3.00$ ls src/.libs/
base.o ioutil.olibnjb.sonjbtime.oprotocol3.o
byteorder.o libnjb.alibnjb.so.5 playlist.o songid.o
datafile.o libnjb.la libnjb.so.5.1.0 procedure.o unicode.o
eax.olibnjb.lai njb_error.o protocol.o usb_io.o
bash-3.00$ cd sample/
bash-3.00$ make
/bin/bash ../libtool --tag=CC --mode=link /opt/SUNWspro/bin/cc
-I../src -g -L/usr/sfw/lib -o cursesplay cursesplay.o
../src/libnjb.la -lcurses -lusb
/opt/SUNWspro/bin/cc -I../src -g -o .libs/cursesplay cursesplay.o
-L/usr/sfw/lib ../src/.libs/libnjb.so -lcurses -lusb -R/usr/local/lib
Undefined first referenced
symbol in file
rpl_malloc ../src/.libs/libnjb.so
ld: fatal: Symbol referencing errors. No output written to .libs/cursesplay
make: *** [cursesplay] Error 1
bash-3.00$
Upon googling I found out about AC_FUNC_MALLOC macro in configure.ac
that checks for correct calling of malloc, and malloc is replaced by
rpl_malloc for incorrect calling.
Workarounds are given at http://wiki.buici.com/wiki/Autoconf_and_RPL_MALLOC
but these appear to be more hacky that a correct workaround. According
to http://cygwin.com/ml/automake/2003-05/msg00043.html that error
comes forward when malloc isn't correctly called.. and thus the
correct thing to do in this situation is patch the source by clearing
this error.
My questions are:
What is the ideal way to patch this error?
What is the best way to patch this error for a spec file?
I removed the -Wall flag from the Makefiles.. however this was said to
be hacky, What is the correct way of going about correcting this
error?
The AC_FUNC_MALLOC is to safeguard against libs that do unsafe memory
allocation.
If someone puts this check in the configure.ac, then one of the two
should be done
a) The author should also put the guard code that introduces
rpl_malloc OR remove the check if not relevant.
b) The person who has downloaded and is using the code should verify
if the compiler does a safe mem allocation and remove it. (if it
doesn't it is a bug against the compiler !)
I feel this check by configure script is useless and may be removed.
Regarding the other question about correct way to do, depending on you
want to use gcc or not do the following
1. If you use gcc, set CC=gcc before calling configure script in the
spec file so that Makefile generated just works.
2. If you use sunpro, then
a) Create a patch that patches the makefile after configure script is
run. This can never be submitted upstream and since it patches a
temporary file, it is kind of hacky. But it works just fine as a quick
solution.
b) Better way would be to introduce a test in configure to test if the
compiler is gcc, and in Makefile template (Makefile.am) you may use
the condition to set the CFLAGS depending on whether compiler is gcc
or not. This way the solution goes into the sources and can be
submitted to the original author. You wouldn't need to maintain the
patch whenever the original sources change.
regards
Shiv
