$ @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
