At 2:58 PM -0400 4/25/04, John E. Malmberg wrote:
Indeed. So Perl is able to build itself and all the core extensions with your modifications?
It seems so. The intent was that unless the C features were enabled, that they would not be visible.
I do not have any feature logicals set for the build. They might affect things, and then the build procedure would have to disable them to protect it self.
--- dist_root:[000000]configure.com_old Sun Apr 11 21:58:27 2004 +++ dist_root:[000000]configure.com Sat Apr 24 22:31:30 2004
Forgive the ongoing nitpicking of your patch style, but unless these filespecs are in unix syntax, folks who have check-in authority are not going to be able to apply it. I know you may not intend the patch to be ready for that yet, but it's getting darn close.
I will have to use the bash shell to change the syntax. The samba/rsync folks seem to be able to accept them. Having never run a patch procedure, I do not know if it cares about what is in the filename, but just uses it as a comment. After all, those lines do not contain anything that the patch program needs to apply the patch.
Lots of stuff that looks ok snipped.
@@ -4384,8 +4422,10 @@ * the argv items and lowercase all of these names. */ for (c = string; *c; ++c) + if (!decc_efs_case_preserve) { if (isupper(*c)) *c = tolower(*c); + } if (isunix) trim_unixpath(string,item,1); add_item(head, tail, string, count); ++expcount;
I would think we'd want to check decc_efs_case_preserve outside the loop.
So do I. I am surprised that I did not see that before. My suspicion is that I put the line in the wrong place. I will change that even though the compiler should know to do the right thing.
more good stuff snipped.
+ s = decc$feature_get_index("DECC$FILENAME_UNIX_REPORT"); + decc_filename_unix_report = decc$feature_get_value(s, 1); + set_feature_default("DECC$FILENAME_UNIX_REPORT", FALSE); + + s = decc$feature_get_index("DECC$FILENAME_UNIX_ONLY"); + decc_filename_unix_only = decc$feature_get_value(s, 1); + set_feature_default("DECC$FILENAME_UNIX_ONLY", FALSE);
But I'm confused on these two. It looks to me like we check for whether the features are enabled and save the setting we inherited from the environment, but then we also explicitly disable the features. If we honor the values we inherit, it seems we would not want to disable them. If we disable them, it seems we would not want to save the values we inherit. What am I missing?
If you leave these features set, it may cause problems when filenames are passed from C routines to RMS or system services.
It may also have other side effects for filenames that are externally displayed, which is probably desired.
To leave these features enabled would require more study of the code to make sure that there are not any problems, and probably some more tests.
But the settings are remembered so that perl will treat "." as UNIX "./", instead of "SYS$DISK:[].;"
Hmm. On this last one we are checking to see if it's already enabled and then re-enabling it?+ } + status = sys_trnlnm("DECC$FILENAME_UNIX_ONLY", val_str, sizeof(val_str)); + if (status) { + _toupper(str[0]) + if ((str[0] == 'E') || (str[0] == 1) || (str[0] == 'T')) { + decc_filename_unix_only = 1; + status = sys_crelnm("DECC$FILENAME_UNIX_ONLY", "ENABLE"); + } + }
That is a bug, Since this is a newer version than the #ifdef, it should not be affecting what I built.
This code was copied from what I did on Python where it was desired to have all internal filenames in UNIX format.
+ + /* CRTL can be initialized past this point, but not before. */ +/* DECC$CRTL_INIT(); */
A side note here.
Putting a DECC$CRTL_INIT() in a lib$initialize psect may have undesired effects if put in a shared image. They get chained, and if a C program is linked with a shared image that has such a call, it will prevent the features from being detected. This was discovered with Python, and the RDB module had to be converted to being dynamically loaded to fix.
So there are two psects, LIB$INITIALIZ and LIB$INITIALIZE ?
Yes. I suspect that the LIB$INITIALIZ psect name is not critical, since the documentation is a bit sparse on that, I would have to either rummage around in the internals, or track down who ever is currently maintaining that code.
Well, now I will see if I can find out why that one test is failing, and then I will look at the two .pm scripts that I am told need a change to build GTK+.
When I actually try to build GTK+, I may find more issues.
-John
