On 09/21/11 12:31, Craig Mohrman wrote:
----- [email protected] wrote:
On Tue, Sep 20, 2011 at 03:17:03PM -0700, Craig Mohrman wrote:
I'm in the process of fixing:
6518266 remove uses of __DATE__ / __TIME__ from perl
so to make life easier for wsdiff and patch creators.
Perl accesses the compilers __DATE__ and __TIME__ and
puts that into the library libperl.so.
So every compile of perl yields a new __DATE__ and __TIME__
giving possible false positives from wsdiff.
perlbug (a perl script) also contains a date inside it.
I was thinking of using a fixed point in time, say solaris fcs,
to just set these variables but these times need to
be updated when real changes happens, or not.
I guess wsdiff can do its job of detecting real binary
or script changes and act accordingly.
Could use some ideas and feedback here.
This build date of perl shows up with perl -V:
$ perl -V | grep Compiled
Compiled at May 28 2011 20:30:29
What about to completely remove such line? Why do we need a date of
compilation
printed?
Thanks Marcel.
I was just concerned if this might be an interface of some sort.
The bigger problem is perlbug.
Maybe we shouldn't even ship perlbug.
Thanks for your input.
I need to think about this more.
I would be inclined to not patch out the use of time/date stamps in
upstream code unless you have worked with the community on it's
removal. One small change is perhaps not a big deal, but code riddled
with embedded stamps is going to cause additional update work. We don't
want to create a set of patches that we will have to perpetually update
with each rev or community fix that we take in.
The right answer is to work with the community to understand why they
think that there is a need to embed time/date stamps in the code and try
to persuade them to remove it's use or find a better alternative.
"built Sep 21, 2011 13:01:02" doesn't really tell you anything more than
the compiler was run against source that generated a particular object
today at 1:01 pm in some timezone. It doesn't actually give you the
specific version of the source + changes that was built, so it's
questionable just how useful it really is.
If the community isn't interested, then the next best thing it to tell
tools that embed date/time stamps (like javadoc) to not embed the stamps
(javadoc -notimestamp) when they run as part of the build.
If you can't do that (C compiler ANSI __DATE__ and __TIME__ macros), the
tools directory of the userland gate includes shared objects that can be
interposed when building a component that can force the compiler and
other tools to use a configurable time constant. See
make-rules/shared-macros.mk and tools/time.c.
It appears that time.c needs a small change to interpose on the right
phase of the Studio compiler, but this is what it looks like:
jacobs@solaris:/tmp$ cat foo.c
#include<stdio.h>
main(int ac, char *av[])
{
printf("DATE: %s, TIME: %s\n", __DATE__, __TIME__);
}
jacobs@solaris:/tmp$ gmake foo
cc foo.c -o foo
"foo.c", line 4: warning: old-style declaration or incorrect type for: main
jacobs@solaris:/tmp$ ./foo
DATE: Sep 21 2011, TIME: 13:28:07
jacobs@solaris:/tmp$ rm foo
jacobs@solaris:/tmp$ gmake LD_PRELOAD_32=/ws/userland-gate/tools/time-i86.so
LD_PRELOAD_64=/ws/userland-gate/tools/time-amd64.so TIME_CONSTANT=0 foo
cc foo.c -o foo
"foo.c", line 4: warning: old-style declaration or incorrect type for: main
jacobs@solaris:/tmp$ ./foo
DATE: Dec 31 1969, TIME: 18:00:00
jacobs@solaris:/tmp$
-Norm
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
