Leo Klein wrote:
$ @link
Linking SMBD
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, DECC$GXSNPRINTF
%LINK-I-UDFSYM, DECC$GXVSNPRINTF
Several of the newer xxxSNPRINTF variants are not in the older CRTL and
are being added to the newer versions.
For older CRTLs, you must supply replacement routines.
When supplying the replacement routine for a standard C library, it must
not have the same public symbol name as the routines, as this will cause
problems.
Some of these problems will be visible at link time, some will not, and
may take quite a bit of effort to find why the code is malfunctioning.
The GXSNPRINTF and GXVSNPRINTF calls can be generated by the compiler
for a variety of public C RTL routines depending on your optimization
settings, so you have to look at the source modules.
It should not be hard to write replacement routines, and likely they are
already present in the SAMBA code, and a change to config.h will make
them active.
For example, a missing VSNPRINTF routine would be replaced with a
routine named rep_vsnprintf, or samba_vsnprintf, or my_vsnprintf.
In the config.h there would be an option:
#define HAVE_VSNPRINTF
or
#undef HAVE_VSNPRINTF
Depending on if your platform supports that call.
In one of the header files, or in the modules that use vsnprintf(),
there would be the following conditional code, or something similar.
#ifndef HAVE_VSNPRINTF
#define vsnprinf samba_vsnprinf
#endif
If you need to supply your own replacement routine, then the above
conditional code would be put in the CONFIG.H file to minimize edits to
the common UNIX SAMBA code.
And even though it seems to be an easy thing to do, do not ever name the
replacement routine the same as a standard C library function.
A good optimizing C complier knows about many of the library routines
and will in line them, so if you are trying to change the behavior of a
standard function, the compiler may not realize that, and inline the
standard function.
Also the link time substitution of user supplied routines covering up
system libraries only works reliably on platforms that do not use shared
images for their libraries.
People who do not heed the above warning usually end up with others that
try to build their code posting on comp.os.vms trying to find out why
they are getting weird build errors after an OpenVMS upgrade or C RTL ECO.
Anything that is using standard C function names for their own public
symbols is virtually guaranteed to eventually not build on OpenVMS.
And several people have posted on the SAMBA Technical list for various
UNIX platforms that have the same problem when SAMBA did the same thing.
-John
[EMAIL PROTECTED]
Personal Opinion Only
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
