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.o libnjb.so njbtime.o protocol3.o > byteorder.o libnjb.a libnjb.so.5 playlist.o songid.o > datafile.o libnjb.la libnjb.so.5.1.0 procedure.o unicode.o > eax.o libnjb.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
