libtool C++ link bug with -lm functions with Sun Workshop compiler

I think I have discovered a bug in libtool's link behavior
with the
Sun Workshop C++ compiler when creating a C++ library that
requires libm.
I observed it on x86_64-sun-solaris2.10, but it may also
affect the
Workshop C++ compiler on Linux too.  I found it when trying
to build
GNU aspell 0.60.5.

If you have a configure.ac that calls AC_LANG([C++]), any
subsequent
AC_CHECK_FUNCS will result in a link that uses the C++
compiler.  Because
the C++ compiler initiates the link, it automatically adds
some libraries
to the final call to ld.  Which libraries it adds depends on
what flags
CC was passed (arguments like -library=stlport4 change what
C++ libraries
are automatically added).  The C++ compiler appears to
always add `-lm
-lc' after the C++ libraries, though.

That means that doing something like


AC_INIT(lttest, 0.60.5)
AC_CONFIG_SRCDIR(configure.ac)
AC_PROG_CXX
AC_LANG([C++])

AC_CHECK_FUNCS(sqrt)
AC_OUTPUT


will always detect sqrt(), because the C++ compiler added
`-lm -lc'
behind the scenes.

When libtool is called to generate a C++ library on Solaris,
it doesn't
add -lm, though.  It only adds -lc.  That will result in
link failures
if functions like sqrt(), floor(), etc. from libm are used
by the C++
library.

Is the correct fix to just add -lm to the postdeps for
Solaris and Linux
when using the Workshop compiler, or is there some other
method that
should be used?  I'm talking about changing all instances
of

       _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd
-library=Crun'

to

       _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd
-library=Crun -lm'

Tim
-- 
Tim Mooney                              mooneydogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076
(Voice)
Room 242-J6, IACC Building              (701) 231-8541
(Fax)
North Dakota State University, Fargo, ND 58105-5164


_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool

On Wed, 19 Mar 2008, Tim Mooney wrote:
> That means that doing something like
>
>
> AC_INIT(lttest, 0.60.5)
> AC_CONFIG_SRCDIR(configure.ac)
> AC_PROG_CXX
> AC_LANG([C++])
>
> AC_CHECK_FUNCS(sqrt)
> AC_OUTPUT
>
>
> will always detect sqrt(), because the C++ compiler
added `-lm -lc'
> behind the scenes.

Then it seems like you did something wrong and libtool is
not to 
blame.  Perhaps it is not best to run most of your configure
script 
using the C++ compiler.  Only run the C++ compiler to test
C++ things.

I use

LT_LANG([C++])

to tell libtool that I need support for C++.  Then I do C++
related 
testing like this

AC_LANG_PUSH(C++)
   some C++ tests
AC_LANG_POP

This works great under Solaris!

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/



_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool

In regard to: Re: libtool C++ link bug with -lm functions
with Sun Workshop...:

> On Wed, 19 Mar 2008, Tim Mooney wrote:
>> That means that doing something like
>> 
>> 
>> AC_INIT(lttest, 0.60.5)
>> AC_CONFIG_SRCDIR(configure.ac)
>> AC_PROG_CXX
>> AC_LANG([C++])
>> 
>> AC_CHECK_FUNCS(sqrt)
>> AC_OUTPUT
>> 
>> 
>> will always detect sqrt(), because the C++ compiler
added `-lm -lc'
>> behind the scenes.
>
> Then it seems like you did something wrong and libtool
is not to blame.

I don't think so.  I discovered the problem with GNU aspell.
 The snippet
I show above is just to illustrate the problem.

> Perhaps it is not best to run most of your configure
script using the C++ 
> compiler.  Only run the C++ compiler to test C++
things.

I don't disagree, but at the same time, if everything a
project is going
to build is going to be compiled by the C++ compiler,
doesn't it make
sense for the C++ compiler to actually do the tests?  If
it's the C++
compiler that needs to see the prototype for sqrt(), and
it's the C++
compiler that's going to initiate the link, it doesn't make
a lot of
sense for the tests to be conducted by the C compiler. 
That's hardly a
good test; there are several reasons why what the C compiler
can see for
prototypes or test link might differ from what the C++
compiler would.

There are projects out there, beyond GNU aspell, that are
using the C++
compiler for many of the configure tests.  Are they all
wrong to do so?

Tim
-- 
Tim Mooney                              mooneydogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076
(Voice)
Room 242-J6, IACC Building              (701) 231-8541
(Fax)
North Dakota State University, Fargo, ND 58105-5164


_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool

On Thu, 20 Mar 2008, Tim Mooney wrote:
>
>> Perhaps it is not best to run most of your
configure script using the C++ 
>> compiler.  Only run the C++ compiler to test C++
things.
>
> I don't disagree, but at the same time, if everything a
project is going
> to build is going to be compiled by the C++ compiler,
doesn't it make
> sense for the C++ compiler to actually do the tests? 
If it's the C++

Good point.  However, it may be that some autoconf tests
intended for 
C don't work properly when used with the C++ compiler.

> compiler that needs to see the prototype for sqrt(),
and it's the C++
> compiler that's going to initiate the link, it doesn't
make a lot of
> sense for the tests to be conducted by the C compiler. 
That's hardly a
> good test; there are several reasons why what the C
compiler can see for
> prototypes or test link might differ from what the C++
compiler would.
>
> There are projects out there, beyond GNU aspell, that
are using the C++
> compiler for many of the configure tests.  Are they all
wrong to do so?

I don't recall if you mentioned the libtool version you are
using. 
Libtool 2.2 usually uses the C++ compiler to link C++
programs and 
libraries.  I just re-verified that it does do so for
Solaris 10 with 
the Studio 12 compiler.  Upgrading to 2.2, or the first
subsequent 
release (scheduled for April 1st) may be the solution you
are looking 
for.

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/



_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool

On Wed, Mar 19, 2008 at 07:03:38PM -0500, Tim Mooney wrote:
>
> I think I have discovered a bug in libtool's link
behavior with the
> Sun Workshop C++ compiler when creating a C++ library
that requires libm.
> I observed it on x86_64-sun-solaris2.10, but it may
also affect the
> Workshop C++ compiler on Linux too.  I found it when
trying to build
> GNU aspell 0.60.5.

What version of Sun C++ are you using?

> If you have a configure.ac that calls AC_LANG([C++]),
any subsequent
> AC_CHECK_FUNCS will result in a link that uses the C++
compiler.  Because
> the C++ compiler initiates the link, it automatically
adds some libraries
> to the final call to ld.  Which libraries it adds
depends on what flags
> CC was passed (arguments like -library=stlport4 change
what C++ libraries
> are automatically added).  The C++ compiler appears to
always add `-lm
> -lc' after the C++ libraries, though.
>
> That means that doing something like
>
> AC_INIT(lttest, 0.60.5)
> AC_CONFIG_SRCDIR(configure.ac)
> AC_PROG_CXX
> AC_LANG([C++])
>
> AC_CHECK_FUNCS(sqrt)
> AC_OUTPUT
>
> will always detect sqrt(), because the C++ compiler
added `-lm -lc'
> behind the scenes.
>
> When libtool is called to generate a C++ library on
Solaris, it doesn't
> add -lm, though.  It only adds -lc.  That will result
in link failures
> if functions like sqrt(), floor(), etc. from libm are
used by the C++
> library.

But if Sun C++ automatically adds -lm -lc, why, with libtool
using C++
to link the library, isn't -lm -lc automatically added?
Because Sun C++
is creating a library and not a program?

-- 
albert chin (chinathewrittenword.com)


_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool

In regard to: Re: libtool C++ link bug with -lm functions
with Sun Workshop...:

> On Wed, Mar 19, 2008 at 07:03:38PM -0500, Tim Mooney
wrote:
>>
>> I think I have discovered a bug in libtool's link
behavior with the
>> Sun Workshop C++ compiler when creating a C++
library that requires libm.
>> I observed it on x86_64-sun-solaris2.10, but it may
also affect the
>> Workshop C++ compiler on Linux too.  I found it
when trying to build
>> GNU aspell 0.60.5.
>
> What version of Sun C++ are you using?

The C++ from Workshop 12 with patches applied:

$CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25

To answer Bob's previous question, I generally upgrade any
project I'm
building to use libtool 1.5.latest, so right now I'm using
1.5.26.

Here's an example.  If you call AC_CHECK_FUNCS(floor) in
configure.ac,
configure ends up with shell code that essentially results
in the
following in conftest.cpp:


/* Define $ac_func to an innocuous variant, in case
<limits.h> declares
  * floor.
    For example, HP-UX 11i <limits.h> declares
gettimeofday.  */
#define floor innocuous_floor

/* System header to define __stub macros and hopefully few
prototypes,
     which can conflict with char $ac_func (); below.
     Prefer <limits.h> to <assert.h> if __STDC__
is defined, since
     <limits.h> exists even on freestanding compilers.
 */

#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif

#undef floor

/* Override any GCC internal prototype to avoid an error.
    Use char because int might match the return type of a
GCC
    builtin and then its argument prototype would still
apply.  */
#ifdef __cplusplus
extern "C"
#endif
char floor ();
/* The GNU C library defines this for functions which it
implements
     to always fail with ENOSYS.  Some functions are
actually named
     something starting with __ and the normal name is an
alias.  */
#if defined __stub_floor || defined __stub___floor
choke me
#endif
int
main ()
{
return floor ();
   ;
   return 0;
}



If you compile that with CC -v, you'll see what libraries
are
automatically added:

$CC -v -o conftest conftest.cpp
###     command line files and options (expanded):
### -v -o conftest conftest.cpp
### CC: Note: NLSPATH =
/opt/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/
opt/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat

/opt/SUNWspro/prod/bin/ccfe -y-o -yconftest.o -y-fbe
-y/opt/SUNWspro/prod/bin/fbe -y-xarch=generic -y-xtab
-y-verbose -O0 -ptf /tmp/16666%1.%2 -ptx
/opt/SUNWspro/prod/bin/CC -ptk "-v  -xs "
-D__SunOS_5_10 -D__SUNPRO_CC=0x590 -Dunix -Dsun -Di386
-D__i386 -D__unix -D__sun -D__SunOS -D__BUILTIN_VA_ARG_INCR
-D__SVR4 -D__SUNPRO_CC_COMPAT=5 -xdbggen=no%stabs+dwarf2
-y-s -xdbggen=incl -I-xbuiltin -xldscope=global
-instlib=/opt/SUNWspro/prod/lib/libCstd.a
-I/opt/SUNWspro/prod/include/CC/Cstd
-I/opt/SUNWspro/prod/include/CC
-I/opt/SUNWspro/prod/include/CC/rw7
-I/opt/SUNWspro/prod/include/cc -y-comdat conftest.cpp -s
/tmp/ccfe.16666.0.s >&/tmp/ccfe.16666.1.err
rm /tmp/ccfe.16666.0.s
### CC: Note: LD_LIBRARY_PATH = (null)
### CC: Note: LD_RUN_PATH     = (null)
### CC: Note: LD_OPTIONS = (null)
ln -s /opt/SUNWspro/prod/lib /tmp/lib_link.16666
ln -s /opt/SUNWspro/prod/lib /tmp/lib_base_link.16666
/usr/ccs/bin/ld -u __1cH__CimplKcplus_init6F_v_
-zld32=-S/tmp/lib_base_link.16666/libldstab_ws.so
-zld64=-S/tmp/lib_base_link.16666/amd64/libldstab_ws.so
-zld32=-S/tmp/lib_base_link.16666/libCCexcept.so.1
-R/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:
/usr/lib -o conftest /opt/SUNWspro/prod/lib/crti.o
/opt/SUNWspro/prod/lib/CCrti.o /opt/SUNWspro/prod/lib/crt1.o
/opt/SUNWspro/prod/lib/values-xa.o -Y
P,/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib:/opt/SUNWspro/prod
/lib/rw7:/opt/SUNWspro/prod/lib:/usr/ccs/lib:/lib:/usr/lib
conftest.o -lCstd -lCrun -lm -lc
/opt/SUNWspro/prod/lib/CCrtn.o /opt/SUNWspro/prod/lib/crtn.o
>&/tmp/ld.16666.2.err
/opt/SUNWspro/prod/bin/stdlibfilt -stderr
</tmp/ccfe.16666.1.err /opt/SUNWspro/prod/bin/fbe -s -o
conftest.o -warn=%none -Qy
/tmp/yabeAAANPayJG
rm /tmp/yabeAAANPayJG
rm /tmp/ccfe.16666.1.err
rm conftest.o
rm /tmp/lib_link.16666
rm /tmp/lib_base_link.16666
rm /tmp/ld.16666.2.err


If you compile the same file using -library=stlport4
(instead of Cstd), CC
still automatically adds -lm (and -lrt, much to my
surprise):

$CC -library=stlport4 -v -o conftest conftest.cpp
###     command line files and options (expanded):
### -v -o conftest conftest.cpp -library=no%Cstd,stlport4
### CC: Note: NLSPATH =
/opt/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/
opt/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat

/opt/SUNWspro/prod/bin/ccfe -y-o -yconftest.o -y-fbe
-y/opt/SUNWspro/prod/bin/fbe -y-xarch=generic -y-xtab
-y-verbose -O0 -ptf /tmp/16672%1.%2 -ptx
/opt/SUNWspro/prod/bin/CC -ptk "-library=stlport4 -v
-xs " -D__SunOS_5_10 -D__SUNPRO_CC=0x590 -Dunix -Dsun
-Di386 -D__i386 -D__unix -D__sun -D__SunOS
-D__BUILTIN_VA_ARG_INCR -D__SVR4 -D__SUNPRO_CC_COMPAT=5
-xdbggen=no%stabs+dwarf2 -y-s -xdbggen=incl -I-xbuiltin
-xldscope=global
-instlib=/opt/SUNWspro/prod/lib/stlport4/libstlport.a
-I/opt/SUNWspro/prod/include/CC/stlport4
-I/opt/SUNWspro/prod/include/CC
-I/opt/SUNWspro/prod/include/CC/rw7
-I/opt/SUNWspro/prod/include/cc -y-comdat conftest.cpp -s
/tmp/ccfe.16672.0.s >&/tmp/ccfe.16672.1.err
rm /tmp/ccfe.16672.0.s
### CC: Note: LD_LIBRARY_PATH = (null)
### CC: Note: LD_RUN_PATH     = (null)
### CC: Note: LD_OPTIONS = (null)
ln -s /opt/SUNWspro/prod/lib /tmp/lib_link.16672
ln -s /opt/SUNWspro/prod/lib /tmp/lib_base_link.16672
/usr/ccs/bin/ld
-zld32=-S/tmp/lib_base_link.16672/libldstab_ws.so
-zld64=-S/tmp/lib_base_link.16672/amd64/libldstab_ws.so
-zld32=-S/tmp/lib_base_link.16672/libCCexcept.so.1
-R/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib/stlport4:/opt/SUNW
spro/lib:/usr/ccs/lib:/lib:/usr/lib -o conftest
/opt/SUNWspro/prod/lib/crti.o /opt/SUNWspro/prod/lib/CCrti.o
/opt/SUNWspro/prod/lib/crt1.o
/opt/SUNWspro/prod/lib/values-xa.o -Y
P,/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib/stlport4:/opt/SUNW
spro/lib:/opt/SUNWspro/prod/lib/rw7:/opt/SUNWspro/prod/lib/s
tlport4:/opt/SUNWspro/prod/lib:/usr/ccs/lib:/lib:/usr/lib
conftest.o -lstlport -lrt -lCrun -lm -lc
/opt/SUNWspro/prod/lib/CCrtn.o /opt/SUNWspro/prod/lib/crtn.o
>&/tmp/ld.16672.2.err
/opt/SUNWspro/prod/bin/stdlibfilt -stderr
</tmp/ccfe.16672.1.err /opt/SUNWspro/prod/bin/fbe -s -o
conftest.o -warn=%none -Qy /tmp/yabeAAAHaaiKG
rm /tmp/yabeAAAHaaiKG
rm /tmp/ccfe.16672.1.err
rm conftest.o
rm /tmp/lib_link.16672
rm /tmp/lib_base_link.16672
rm /tmp/ld.16672.2.err


>> will always detect sqrt(), because the C++ compiler
added `-lm -lc'
>> behind the scenes.
>>
>> When libtool is called to generate a C++ library on
Solaris, it doesn't
>> add -lm, though.  It only adds -lc.  That will
result in link failures
>> if functions like sqrt(), floor(), etc. from libm
are used by the C++
>> library.
>
> But if Sun C++ automatically adds -lm -lc, why, with
libtool using C++
> to link the library, isn't -lm -lc automatically added?
Because Sun C++
> is creating a library and not a program?

I believe that's exactly correct.  Because a (shared)
library is being
built by the C++ compiler, libtool is using "CC
-G", and -G implies

                When you use the -G option, the compiler
does not
                pass any default -l options to ld. If you
want the
                shared library to have a dependency on
another
                shared library, you must pass the necessary
-l
                option on the command line. For example, if
you
                want the shared library to be dependent upon
lib-
                Crun, you must pass -lCrun on the command
line.

libtool knows this, and there is code in place (which you
authored)
to automatically add '-library=Cstd -library=Crun' plus -lc
in the event
that '-library=stlport4' is NOT part of CXXFLAGS and you're
doing a C++
link.

So although libtool is being very helpful by automatically
adding
-library=Cstd -library=Crun -lc when creating a shared
library, it is
not adding the same set of libraries that CC alone would add
when linking a
program.

Tim
-- 
Tim Mooney                              mooneydogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076
(Voice)
Room 242-J6, IACC Building              (701) 231-8541
(Fax)
North Dakota State University, Fargo, ND 58105-5164


_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool

On Fri, 21 Mar 2008, Tim Mooney wrote:
>> What version of Sun C++ are you using?
>
> The C++ from Workshop 12 with patches applied:
>
> $CC -V
> CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25

% CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-02 2007/12/18

> To answer Bob's previous question, I generally upgrade
any project I'm
> building to use libtool 1.5.latest, so right now I'm
using 1.5.26.

Maybe you should be trying 2.2 since support for the Solaris
compiler 
has been redone so that linking is via the C++ compiler for
C++ code. 
In spite of a few known bugs (many fixed now), the 2.2
version is much 
better than preceding versions due to its exhaustive test
suite and 
quite a few years more development.

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/



_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool

In regard to: Re: libtool C++ link bug with -lm functions
with Sun Workshop...:

>> To answer Bob's previous question, I generally
upgrade any project I'm
>> building to use libtool 1.5.latest, so right now
I'm using 1.5.26.
>
> Maybe you should be trying 2.2 since support for the
Solaris compiler
> has been redone so that linking is via the C++ compiler
for C++ code.

In the case of aspell, which is where I discovered this
issue, 1.5.26 was
using the C++ compiler to do the link (for both the library
creation and
eventual program creation).  I know that there are other
projects that
mixed C and C++ code and weren't correctly being linked by
the C++
compiler -- in fact I reported that issue a few weeks ago. 
2.2 is a
definite improvement there.

I tried 2.2 for this issue, though, and no improvement over
1.5.26:


Making all in .
gmake[1]: Entering directory
`/local/src/RPM/BUILD/aspell-0.60.5'
/bin/bash ./libtool --tag=CXX   --mode=link CC  -xO2
-xtarget=native -m64 -xarch=native -I/local/gnu/include
-I/local/gnu/include -version-info 16:4:1 -no-undefined
-L/local/gnu/lib/64 -L/local/gnu/lib/64 -o libaspell.la
-rpath /local/gnu/lib/64 common/cache.lo common/string.lo
common/getdata.lo common/itemize.lo common/file_util.lo
common/string_map.lo common/string_list.lo common/config.lo
common/posib_err.lo common/errors.lo common/error.lo
common/fstream.lo common/iostream.lo common/info.lo
common/can_have_error.lo common/convert.lo
common/tokenizer.lo common/speller.lo
common/document_checker.lo common/filter.lo
common/objstack.lo common/strtonum.lo common/gettext_init.lo
common/file_data_util.lo
modules/speller/default/readonly_ws.lo
modules/speller/default/suggest.lo
modules/speller/default/data.lo
modules/speller/default/multi_ws.lo
modules/speller/default/phonetic.lo
modules/speller/default/writable.lo
modules/speller/default/speller_impl.lo
modules/speller/default/!
 phonet.lo modules/speller/default/typo_editdist.lo
modules/speller/default/editdist.lo
modules/speller/default/primes.lo
modules/speller/default/language.lo
modules/speller/default/leditdist.lo
modules/speller/default/affix.lo modules/tokenizer/basic.lo
lib/filter-c.lo lib/word_list-c.lo lib/info-c.lo
lib/mutable_container-c.lo lib/error-c.lo
lib/document_checker-c.lo lib/string_map-c.lo
lib/new_config.lo lib/config-c.lo
lib/string_enumeration-c.lo lib/can_have_error-c.lo
lib/dummy.lo lib/new_filter.lo lib/new_fmode.lo
lib/string_list-c.lo lib/find_speller.lo lib/speller-c.lo
lib/string_pair_enumeration-c.lo lib/new_checker.lo
modules/filter/url.lo  -L/local/gnu/lib/64 -lintl
-L/local/lib/64 -lc -R/local/gnu/lib/64  -ldl 
libtool: link: CC -G -zdefs -hlibaspell.so.15 -o
.libs/libaspell.so.15.1.4   common/.libs/cache.o
common/.libs/string.o common/.libs/getdata.o
common/.libs/itemize.o common/.libs/file_util.o
common/.libs/string_map.o common/.libs/string_list.o
common/.libs/config.o common/.libs/posib_err.o
common/.libs/errors.o common/.libs/error.o
common/.libs/fstream.o common/.libs/iostream.o
common/.libs/info.o common/.libs/can_have_error.o
common/.libs/convert.o common/.libs/tokenizer.o
common/.libs/speller.o common/.libs/document_checker.o
common/.libs/filter.o common/.libs/objstack.o
common/.libs/strtonum.o common/.libs/gettext_init.o
common/.libs/file_data_util.o
modules/speller/default/.libs/readonly_ws.o
modules/speller/default/.libs/suggest.o
modules/speller/default/.libs/data.o
modules/speller/default/.libs/multi_ws.o
modules/speller/default/.libs/phonetic.o
modules/speller/default/.libs/writable.o
modules/speller/default/.libs/speller_impl.o
modules/speller/default/.libs/phonet.o!
  modules/speller/default/.libs/typo_editdist.o
modules/speller/default/.libs/editdist.o
modules/speller/default/.libs/primes.o
modules/speller/default/.libs/language.o
modules/speller/default/.libs/leditdist.o
modules/speller/default/.libs/affix.o
modules/tokenizer/.libs/basic.o lib/.libs/filter-c.o
lib/.libs/word_list-c.o lib/.libs/info-c.o
lib/.libs/mutable_container-c.o lib/.libs/error-c.o
lib/.libs/document_checker-c.o lib/.libs/string_map-c.o
lib/.libs/new_config.o lib/.libs/config-c.o
lib/.libs/string_enumeration-c.o
lib/.libs/can_have_error-c.o lib/.libs/dummy.o
lib/.libs/new_filter.o lib/.libs/new_fmode.o
lib/.libs/string_list-c.o lib/.libs/find_speller.o
lib/.libs/speller-c.o lib/.libs/string_pair_enumeration-c.o
lib/.libs/new_checker.o modules/filter/.libs/url.o  
-R/local/gnu/lib/64 -R/local/gnu/lib/64 -L/local/gnu/lib/64
/local/gnu/lib/64/libintl.so -L/local/lib/64 -lc -ldl
-library=Cstd -library=Crun -lc   -xtarget=native -m64
-xarch=native 
Undefined			first referenced
  symbol  			    in file
log                                 common/.libs/convert.o
sqrt                               
modules/speller/default/.libs/readonly_ws.o
floor                               common/.libs/convert.o
ld: fatal: Symbol referencing errors. No output written to
.libs/libaspell.so.15.1.4
gmake[1]: *** [libaspell.la] Error 1
gmake[1]: Leaving directory
`/local/src/RPM/BUILD/aspell-0.60.5'
gmake: *** [all-recursive] Error 1


By visual inspection, it doesn't look like the relevant code
in libtool.m4
that automatically adds `-library=Cstd -library=Crun' has
changed in any
significant manner since 1.5.2X.

Tim
-- 
Tim Mooney                              mooneydogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076
(Voice)
Room 242-J6, IACC Building              (701) 231-8541
(Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool