linking problem (slprintf)

[John E. Malmberg]

I do not have the source in front of me, so this is from my memory, having
chased this down last week on OpenVMS.

In one of the header files, there should be a #define slprintf snprintf

If your architecture does not have a snprintf functions, apparently the
configure script should have caused the module snprintf.c to be built and
included in the link.


In my case it did not work.  The I was getting duplicate symbol errors as
the test macro to determine if snprintf() and vsnprintf() should be
included was looking for either of HAVE_SNPRINTF or that longer string
about SNPRINTF with C99 in it to be undefined.  It looks like an "||"
should really be a "&&" in the preprocessor statement.


Programming note:

Providing routines like ?printf() type to cover system routines with the
same names can be problematic for an optimizing compiler.

The compiler knows that instead of making one call to the
?printf() routine, it can make individual calls to built in routines that
can more efficiently build the resulting string.  This optimization is
generally done only if the function shows up in a compiler supplied header
file.

This means that the modules are are expected to call the replacement
snprintf() routine will not actualy do so unless default optimizations are
disabled.  The way to prevent this from happening is to give the
replacement routine a unique name, such as samba_snprintf().

Any place where you have use a system library call name for a local
function or even as a member of a structure, you run the risk of either
breaking a compiler's optimizer, or conflicting with a preprocessor
macro in a system supplied header.

The function pointers in the vfs structure also have this problem because
their arguments are not exactly the same as the system functions that
share the same name.  When one of those system functions are implemented
with a preprocessor macro, a compilation error will occur.


If you want portable code, the system routine names must be considered
to be reserved words.

I can only reproduce the vfs structure problems on my OpenVMS build, but
the snprintf() issues can also show up on at least TRU-64 and LINUX on
ALPHA as they can all use the same compiler.


-John
wb8tyw at qsl.network
Personal Opinion Only

On Wed, 4 Jul 2001, Stan Sander wrote:

> Using CVS from this morning, I get the following linking errors.  Suse
> 7.1 System, 2.4.3 kernel, glibc 2.2, gcc 2.95.2
> 
> Linking bin/smbd
> smbd/dfree.o: In function `disk_free':
> smbd/dfree.o(.text+0x228): undefined reference to `slprintf'
> smbd/mangle.o: In function `mangle_name_83':
> smbd/mangle.o(.text+0x1065): undefined reference to `slprintf'
> smbd/close.o: In function `check_magic':
> smbd/close.o(.text+0x141): undefined reference to `slprintf'
> libsmb/clierror.o: In function `cli_errstr':
> libsmb/clierror.o(.text+0x81): undefined reference to `slprintf'
> libsmb/clierror.o(.text+0xa5): undefined reference to `slprintf'
> libsmb/nmblib.o(.text+0x674): more undefined references to `slprintf'
> follow
> collect2: ld returned 1 exit status
> make: *** [bin/smbd] Error 1
> 
> --
> Stan Sander - CSU Special Projects      Sandia National Laboratories
> (505) 284-4915                          Mail Stop 0662
>                                         1515 Eubank SE
>                                         Albuquerque, NM 87123