Re: SAMBA for VMS (The saga continues!)
From: John Malmberg (malmberg_at_dskwld.zko.dec.compaq.hp)
Date: 08/18/05
- Next message: John Malmberg: "Re: SAMBA for VMS (The saga continues!)"
- Previous message: Z: "Re: How many files can you have in a VMS directory without performance problems?"
- In reply to: Steven M. Schweda: "Re: SAMBA for VMS (The saga continues!)"
- Next in thread: Bill Gunshannon: "Re: SAMBA for VMS (The saga continues!)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 17 Aug 2005 23:13:59 GMT
Steven M. Schweda wrote:
> From: John Malmberg <malmberg@dskwld.zko.dec.compaq.hp>
>
>>> Why does the use of the funny names constitute "The correct fix"?
>>
>>Because it is the only way to prevent conflicts with the compiler
>>optimizer and with shared images that may be loaded on any platform.
>
>
> My goal is to have source code which will use the system RTL
> functions where available, and which will use substitutes where the
> system RTL lacks something. So far as I can tell, because the system
> RTL function complement depends on local conditions, the victim is
> always required to compile the calling code (with its __CRTL_VER
> dependence). Given that, the added burden on having to compile the
> callee (substitute function) code seems small to me.
The __CRTL_VER should be in the CONFIG.H or equivalent. Most Open
Source packages now use that flavor.
The stuff I did with rsync (still slowly making progress) uses a DCL
procedure to generate the CONFIG.H and the automatically generated
CONFIG.H contains #include "config_vms.h". The config_vms.h is manually
edited for the things that the DCL procedure can not calculate.
If you are manually generating a CONFIG.H file, then you can tune it for
the VMS versions that you are targeting.
The __CRTL_VER symbol is one thing that you can use at compile time to
determine that the OS routine is now available. The alternative is to
have a configure script that tries to figure out what is or is not present.
>>It is only if you are using only object libraries and specific linking
>>instructions and also disabling the compiler optimizer that you can rely
>>on the original UNIX behavior of overlaying operating system supplied
>>routines with ones in your program that are in separate modules.
>
> I don't expect any overlaying. I expect %CC-I-IMPLICITFUNC and
> %LINK-I-UDFSYM when I try to use something which is missing, and some
> kind of MULDEF if I try to supply something which is already there.
> (Then I look at this week's header files to figure out how to condition
> the code to remove the complaints.)
The MULDEF is what causes angry posters to show up on comp.os.vms after
they upgrade VMS and then try to install an existing package. And it is
easily avoided by treating the UNIX library names as reserved symbol names.
When a problem is easy to prevent, it should be prevented.
> I don't see what sense it would make for the the compiler to be
> optimizing somehow with regard to RTL functions which are not available
> on the local system, but what do I know?
The compiler is maintained on a different release schedule than for the
operating system, and has components that are common to other operating
systems.
Therefore the compiler may have knowledge of things that are not yet in
the operating system. For some calls like the "printf" family, there
are common optimizations that apply to all of the variants.
In the case of snprintf(), the compiler knew about it and how to
optimize it for while before it finally showed up in the CRTL.
>
>>[...] you may not get the result you thought you were getting even on UNIX,
>>even if you are not getting compile or link errors, if you were
>>intending on having a routine do something different than the standard
>>routine with the same name.
>
>
> The intention is simply to substitute for a _missing_ RTL function.
> I'll gladly admit that a differently-working function with a standard
> name would be a bad idea.
But what is missing today may not be missing tomorrow.
And substituting differently working functions is common for debugging
malloc() type issues or adding profiling libraries.
In these cases the public symbol name needs to be unique, and a macro is
used to cause it to be used instead of the standard library.
In some cases, I have seen replacement routines used because the
configure script determines that the supplied run-time routine has a bug
in it. Of course the configure scripts usually do not know how to set
the options needed for a platform to generate a call to a fixed routine
that it supplies.
>
>>As OpenVMS improves their compliance with the X/Open UNIX specification,
>>it will cause more problems with routines that are using these names as
>>global symbols.
>
> So far as I can see, an improved RTL will cause problems for anyone
> who provides any substitute function with any name, standard or goofy,
> unless he can somehow divine what the magic __CRTL_VER value will be to
> determine its availability. I don't see what the goofy names buy you in
> this case either.
If you need to provide a routine because the CRTL is missing foo(), you
provide the routine with a name like my_foo().
Then in the config.h file you put in:
#define foo my_foo
Now your source code will compile/link/run with the current versions of
VMS and any following updates for the CRTL that show up.
Now if a new version of VMS shows up with foo() implemented on it, then
you can either put in a test in your configure script to detect it, or
if you are like most people that are manually maintaining the config.h
files you can put the __CRTL_VER test in so that it does not substitute
the routine on the newer version.
This allows you to have one source code distribution that will continue
to work on older version of VMS or the CRTL.
>>And if you want your code to work properly on a wide variety of UNIX
>>like systems you will also want to follow the same practice.
>
> Which is why no one there needs to use "configure" scripts to test
> everything in situ?
I do not understand your statement. The duplicate symbol issue has
shown up on the SAMBA-TECHNICAL list a few times because it has
prevented the building of SAMBA on a particular UNIX that was not
participating in the daily build.
In this case the replacement routines in SAMBA were needed because the
ones supplied on the platform did not pass the configure test for
correct results, but the link failed because of the duplicate symbols.
And it seems to take at least a week for even minor changes to the
configure scripts to start producing apparently correct results on all
platforms participating in the daily builds.
And many errors in configure scripts simply go unnoticed until it is
discovered that some routine is not working right.
> I can see where, if you wanted to build an object library containing
> substitute functions, and always link with it, it would make some sense
> to use goofy names on the substitutes. However, if a __CRTL_VER
> dependence means that you have to compile almost everything anyway, the
> value of such an object library would seem (to me) to be pretty limited.
The __CRTL_VER is used when you are manually editing the config.h file
so that it can support older versions of VMS as well as the current.
If you are using a configure script to test what is there, then you do
not need to use the __CRTL_VER.
In the case of SAMBA 2.2.8, the config.h file is manually generated, so
using the __CRTL_VER is the way to determine if the substitute routines
should be used by the rest of the code.
The COMPILE.COM and LINK.COM can also be conditionalized not to include
the module with the substitute routines if a full build is done.
But by having the goofy names, object modules that are built on the
oldest version of VMS supported can be relinked on the newest and still
work the same way. And SAMBA 2.2.x needs to be linked against the
system image, so .EXE files can not be distributed.
If you use the "goofy" names, then your if your source code builds on a
given version of VMS, it will continue to build on VMS unless someone at
X/Open just happens to decide to name a function with the "goofy" name
that you picked and that function was needed enough that it got put in
to VMS.
If you use the same names for missing routines, then you may have to
edit your source code and recompile before you can relink after any ECO
or VMS upgrade.
We have been having people showing up complaining about these easily
preventable multiple global symbol warnings on comp.os.vms at least
every 6 months for the past several years.
For people that use freeware that do not have a compiler or the
programming skills to do a rebuild of the project, then this becomes a
show-stopper bug until they can contact who ever supplied the project
to get a new kit.
And some freeware with this problem has been only distributed in object
module form.
-John
malmberg@dskwld.zko.dec.compaq.hp
Personal Opinion Only
- Next message: John Malmberg: "Re: SAMBA for VMS (The saga continues!)"
- Previous message: Z: "Re: How many files can you have in a VMS directory without performance problems?"
- In reply to: Steven M. Schweda: "Re: SAMBA for VMS (The saga continues!)"
- Next in thread: Bill Gunshannon: "Re: SAMBA for VMS (The saga continues!)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
