help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Archive member timestamps on Solaris 2.8?


From: David Featherstone
Subject: RE: Archive member timestamps on Solaris 2.8?
Date: Thu, 31 Oct 2002 15:18:48 -0500

Resend – Just in case Paul Smith is not the only help resource.

 

-----Original Message-----
From: David Featherstone [mailto:address@hidden
Sent:
Thursday, October 31, 2002 1:43 PM
To: 'address@hidden'
Subject: RE: Archive member timestamps on Solaris 2.8?

 

Hi Paul

 

Upgrading from 3.79.1 to 3.80 via  pkg-get -u, I see that gmake now correctly updates archive members, but new problems have resulted. These problems are probably of my own creation rather than any bug in gmake, but your insight would be appreciated.

 

Prior to my use of archive members as targets, my Makefile successfully built both .o object files and .d dependency files from their corresponding .pc Pro-C source files. Moreover, that Makefile preserved any .o file after adding it to an archive and correctly deleted intermediate .cc files. (Note that Oracle’s Pro-C generates a .cc file from a given .pc and that Sun’s Forte C++ compiler then generates the corresponding .o and .d files from this .cc file.)

 

Since the upgrade to 3.80 and the concurrent adoption of archive member syntax, my Makefile now:

  • fails to create the .d dependency files and
  • automatically removes both the .o and .cc files (rather than just the .cc file)

 

I can speculate that the second bullet, above, describes correct behaviour, assuming that I interpret the archive member as the target and the .o as an intermediate. So far, however, I cannot rationalize the behaviour described in the first bullet:

 

TARGET = solaris_d/

 

$(lib1)(%) : % $(MAKEFILE)

        address@hidden [ ! -d $(@D) ]; then $(MKDIR) $(@D); fi

        $(strip $(AR) $(ARFLAGS) $@ $%)

 

%.cc : %.pc

        $(PROC) $(PROCPPFLAGS) $(PROC_INC_PATH) $(PROC_OPTS) iname=$* >

 

$(TARGET)%.o : %.cc

        address@hidden [ ! -d $(TARGET) ]; then $(MKDIR) $(TARGET); fi

        $(CCC) $(CC_FLGS) $(CC_OPTS) -c $< -o $@

 

dep :: $(DEP)

 

$(TARGET)%.d :: $(XIDL_HH)

 

$(TARGET)%.d :: $(IDL_HH)

 

$(TARGET)%.d :: %.cc

        @echo Generating Makefile dependencies for $<

        @if [ ! -d $(TARGET) ]; then $(MKDIR) $(TARGET); fi

        @$(MKDEPEND) $(CC_FLGS) $(CC_OPTS) $< \

        | sed "s%\($(*)\)\.o[ :]*%$(TARGET)\1.o $(@) : %g" > $(@)

 

As you can see, I have chained rules both to get .d files from .pc files and likewise to get .o files from .pc files. When I clobber the archive and re-make, all targets – except for the .d files – are built. If I explicitly provide a .d target on the command line, gmake tells me that there’s no rule to create the corresponding .cc file, which seems bogus since the same rule was used to create the .o file:

 

% gmake solaris_d/foo.d

gmake: *** No rule to make target `foo.cc', needed by `solaris_d/foo.d'.  Stop.

 

but my conundrum follows because the following command succeeds:

 

% gmake solaris_d/foo.o

proc iname=foo >

CC -g -c foo.cc -o solaris_d/DalOperationalIFC.o

 

Any suggestions?

 

Regards,

… Dave

Archive member timestamps on Solaris 2.8?

Paul D. Smith Paul D. Smith" <address@hidden
Wed, 20 Jun 2001 16:00:04 -0400


You need to build make with the --disable-nsec-timestamps flag.
 
The UNIX format for archive members allows only the standard 32-bit
timestamp, so it doesn't work with sub-second timestamps.
 
In the next version of GNU make, there's a more discrete capability for
specifying which targets should be considered to not be able to handle
sub-second timestamps, but for 3.79.1 you must disable it completely
(all or nothing).
 
-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
 
 

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]