At 03:41 PM 4/20/00 -0600, Eric F. Richards wrote:
> > At 03:14 PM 4/20/00 -0600, William Atkinson wrote:
> > >Yes, it is definitely a conflict in header files. I talked with the
> vms guy
> > >here and it turns out that we are comitted to keeping them so that we can
> > >generate product versions that look like they came from older vms
> releases.
> >
> > Then he's doing things the wrong way, as you've found, as it crocks the
> > current version's build. There are better ways to do it. (Keeping an old
> > Alpha or VAX in the cluster's the best one... :) But it sounds like you're
> > stuck with things the way they are.
>
>So's the VMS guy... that'd be me. I complained long and hard about it
>and was overrulled. Anyway, enough politics...
Gah. Well, you've got my sympathies. Has anyone considered a shadow
SYS$LIBRARY that can be locally set for builds that need the old stuff? But
that's neither here nore there. (I know folks that do this with the
alternate pthreads libraries the java ECO kit installs)
>I hadn't seen this sort of conflict before -- for our "problem" we usually
>list SYS$LIBRARY as an /INCLUDE directive. If I want to write "real" code
>I've not had this problem.
>
>I admit to being ignorant on the Perl build procedure -- does it list
>SYS$LIBRARY and/or POSIX$INCLUDE as /INCLUDE directories?
Nope. Perl only sets its includes to extra goodies it needs and assumes the
environment it lives in is reasonably normal. The list of libraries has
varied a bit over various versions of the C compiler, so it's the best
general strategy.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
