Re: Compiling SAMBA with better options
From: B. Z. Lederman wrote: I've been looking more at the source code and the way it's compiled. /STANDARD=VAXC is really not a good choice. It covers up too many real and potential problems in the code. Use /STANDARD=PORTABLE. Do not use /STANDARD=VAXC Use /WARN=ENABLE=(LEVEL4, QUESTCODE) for the diagnostic level. You can use more strict /STANDARD or /warn and other checking if you wish, but the two settings above are the minimum needed to both find common bugs, and to be compatable with common programming practices. If the /warn=enable=(LEVEL4, QUESTCODE) and /STANDARD=PORTABLE does not compile a UNIX samba module, try it again by adding /ACCEPT=NOVAXC If that does not fix it, then update the source and send a explanation of the bug fix allong with a submit a gdiff -u output of the change to the SAMBA-TECHNICAL list so it can be fixed in the source for all platforms. If you have not submitted patches to the SAMBA-TECHNICAL list before, I recommend posting just the lines that you think needing fixing both old and new to this list for review. Please be brief. There is also a question of what to do with names that are longer than 31 characters. I put #define statements in the config.h or equivalent. Having the names truncated will cause duplicate symbol errors in SAMBA. The only thing that I can find in the standard is that only 8 characters for external names are guaranteed to be available on all platforms, and obviously most code needs more than that. The other option is to allow the compiler to mangle names. I prefer not to do that as then I can not always predict what name will show up in the debugger. Particularly if the demangle database is cleared. [SAMBA-2_2_7A-SRC.SOURCE.SMBD] CLOSE.C because it calls sys$open, sys$close, etc. without the functions being defined. Modules that call these functions are better off if they #include starlet.h to define the function prototypes. There are a couple of other modules where this should be done. I personally find that the #include files for the system service modules to not be accurate because they do not use the const modifier where they should and they tend to use void *, which will accept anything with out a complaint. So I usually prototype the system services manually, like I did in Frontport. That way the compiler is more likely to find bugs. The use of the const modifier on variables passed by address also allows the compiler to optimize more effienciently, which means faster and smaller code. It's use should be greatly encouraged. An unknown person wrote: (post is not in the digest) | I quite agree with your remarks, but I fear that you seem to forget a very | important point : Samba/VMS is a port from a quite complicated software that | comes from Unix, and is quite often updated. If you multiply the #ifdef | for VMS specifics, you begin to have a lot of work each time a new release | comes in, if you want to follow the Unix updates. So I tend to limit the VMS | specific changes to truly functional ones, not for the intellectual benefit | of removing warning or informational messages. That is why I did the SAMBA 2.0.6 port the way I did. Amost no #ifdef __VMS is in the code. Carl Perkins has supplied me with a fix to Frontport that probably eliminates all but one of the #ifdef __VMS. Use of the compiler options that I listed earlier should allows SAMBA to compile unless there is a real bug in the source code. I add a /DEFINE=(MOD_modulename) to the MMS C compiler rule so that I can put things that are specific to a module in the config.h or equivalent. That way I can override a local routine with out having to edit any source code. The MMS definition is below, and it is easy to do this with DCL command procedures. MODN =MOD_'f$element(0,-,f$parse($*,,,NAME))' So in the config.h or equivalent, (Since I am now generating the config.h from a command procedure that knows how to read the config.h.in and configure.in files, and search the DECC images and libraries, I now put all the manual edits in config_vms.h) #ifdef MOD_LOADPARM /* Change the name for a VMS specific wrapper */ /**/ #define lp_load samba_lp_load #endif This allows me to scan the VMS specific SAMBA logical names every time that SAMBA scans the smb.conf file for changes. And if a module informational diagnostics that I do not want to submit a fix for, I can supress those on a per module basis. #ifdef MOD_IPC /* suppress messages about using -1 as third arg to SSVALS() macro */ #pragma message disable intconstsign #endif This is a case where they are using a -1 instead of 0xFFF. The problem with fixing this is that the size of an unsigned int is platform specific, so it really should be ~0 instead. However if I remember correclty that also generates a diagnostic. So I just supress the diagnostic for now. An unknown person wrote: (post is not in
RE : Compiling SAMBA with better options
| I quite agree with your remarks, but I fear that you seem to forget a very | important point : Samba/VMS is a port from a quite complicated software that | comes from Unix, and is quite often updated. If you multiply the #ifdef | for VMS specifics, you begin to have a lot of work each time a new release | comes in, if you want to follow the Unix updates. So I tend to limit the VMS | specific changes to truly functional ones, not for the intellectual benefit | of removing warning or informational messages. I do know where the code comes from, and I'm not proposing the addition of any #ifdef s at all. The modules that should be including STARLET.H are VMS only or are already conditionalized for VMS, because only VMS-specific code will be calling sys$open, sys$truncate, etc. As for the other warnings: they are indications of problems in the common code. Comparing an unsigned integer to a signed value is something that should not be done on any platform. The OpenVMS C compiler is warning of things that should be fixed on all platforms in the common code. | them on the Internet. I was not too much enthusiast, but I eventually | agreed, and since then I try to do my best to help other users who encounter | problems. May I say that since the beginning of this Samba/VMS version (more | or less 1 year ago), not a single problem was due to the /STAND=VAXC option | ? I'm sure your efforts are appreciated. Unfortunately, you can't be sure you don't have problems due to the compiler options. Compiling /STAND=VAXC means that warning messages about code that could be causing problems are not seen. You are also losing out on improvements the compiler can make to the code. I'm trying to make the results of my compilation run available to everyone who wants it. I hope someone would know how to pass back the information to the people who are 'responsible' for the common code so the major problems can be fixed. I also think the improved compiler switches would be good for everybody running on OpenVMS. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Compiling SAMBA with better options
I've been looking more at the source code and the way it's compiled. /STANDARD=VAXC is really not a good choice. It covers up too many real and potential problems in the code. I decided to try compiling with a better set of options which I have included below. (the /ARCH = HOST isn't essential, but it helps if the code is going to execute on the same architecture as it's compiled.) I got a lot of warnings about locally declared prototypes (PROTOSCOPE): these aren't always problems, but they can be if the function is used in more than one place. So I have (for now) told the compiler not to issue any warnings about that one particular potential problem. There are other checks that could be included in the /CHECK qualifier, and when the currently known problems are addressed perhaps a /CHECK or even a /CHECK=ALL should be done. There is also a question of what to do with names that are longer than 31 characters. I don't know what ANSI says about it, but they're a potential problem on OpenVMS. There is work going on to address this, but for now removing the /STANDARD=VAXC means usually choosing a method of dealing with names. I tried /NAMES = (AS_IS, SHORTENED) which shortens the names in a predictable manner. However, I got errors linking the executables because some names didn't match. I think /NAMES = (UPPERCASE, SHORTENED) would be better and I intend to try that. A lot of the code compiles cleanly with this set of options, which it should. When the compiler flags something, it's usually a real problem, and something which would be a problem on any platform. For example, there are many cases where an unsigned variable is being compared to a signed constant or value. I also edited two modules: [SAMBA-2_2_7A-SRC.SOURCE.VMS] VMS_SUPPORT.C for the previously discussed problem with getdvi instead of getdviw and [SAMBA-2_2_7A-SRC.SOURCE.SMBD] CLOSE.C because it calls sys$open, sys$close, etc. without the functions being defined. Modules that call these functions are better off if they #include starlet.h to define the function prototypes. There are a couple of other modules where this should be done. The compiler command I used is: $ cc := CC/DECC/NOLIST/INCLUDE=([],[.INCLUDE],[.UBIQX],[.SMBWRAPPER],[.tdb],[.popt],[.VMS]) - /DEFINE=(WITH_SMBPASSWD_SAM, HAVE_IFACE_IFCONF) /NESTED = PRIMARY - /ARCH = HOST /ASSUME = WHOLE /CHECK = (UNINIT, POINTER = ALL) - /LIST /CROSS /SHOW = BRIEF /PREFIX = ALL /OPT = LEVEL = 5 - /NAMES = (AS_IS, SHORTENED) /WARN = DISABLE = PROTOSCOPE The number of modules with warnings is longer than I would post to the mailing list by default (if you include the entire message, which includes a pointer to the code with an explanation). I can mail it, or you can pick it up from a web site. My personal web site is: http://encompasserve.org/~lederman/index.html There should be a pointer to samba1.txt and samba1.zip which has the results of my compilation. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
