If you build from one directory, then update one of the library's
members and build from another directory, the object file isn't seen as
the same object file because the paths are different.
So your updated object file is now in the library twice. cd to where
the library lives and jam clean.
Unlike ar, lib.exe stores the path specified on the command line of the
object files in the resulting library. This is a problem for us too.
I suppose it could be solved by modifying the Library rule to be in the
directory of the object files when updating the library, but this
becomes a hard problem to solve when the object files are all over the
place.
Add it to the very long list of stupid MS behaviors in their tools.
(You should see the tricks I had to do just to get parallel builds
working properly)
On Feb 11, 2004, at 7:26 PM, Marco Pappalardo wrote:
warning : myfunction() already defined in mylib.lib, ignoring second
definition.
Am I right to assume from this message that the old code for
myfunction() is not being replaced by the new code for myfunction() ?
Any ideas on how to fix this ?
8 messages in com.perforce.jamming[jamming] xxx already defined in lib,...