Link problems with V2.2.8

[John E. Malmberg]

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
wb8tyw at qsl.net
Personal Opinion Only