bds2006 ide project linking woes
dhoke
links on machine A without error.
Same project fetched from source control on machine B opened in IDE, when
asked compiles everything, but consistently fails to link with several
unresolved items.
Command lines turned on for IDE on machine B.
IDE reported command line for linking on machine B copied and executed in an
appropriate command line environment, links without error. (Necessary to
remove -GA items from the copied command-line - they apparently redirect
project items to temporary files that are used to store current state of
possibly edited items open in the IDE.)
Any ideas why the in-IDE linking is consistently failing on machine B, when
it seems fine on machine B from a command prompt, and fine on machine A
within the IDE?
Any suggestions of how to get around this (with B/CG provided
items/features)? (I'm aware of the alternative linker, but would prefer a
solution involving B/CG provided tools.)
An attempt to use the ilink32.exe from CB2007 trial did not make any
difference, still get same errors from IDE link attempt. (Don't know if the
standalone executable is actually referenced from the IDE, but we thought
we'd try it.)
Machine B (4GB memory)
Machine A (2GB memory)
Both have bds2006, update2, hotfixed (I think through 12)
dhoke
Opening the project that built without error on machine A across a mapped
network drive (actual project location still on machine A drive), with the
IDE installation on machine B and attempting complete re-build, results in
the same errors that occurred with the project hosted on machine B's drive.
The absence of the -GA is not the reason the command-line works in the
command prompt.
On machine B project location, we have manually created the "temporary"
files, and used the command-line with the "-GAs" as copied from the IDE
build log, and it still links from the command-line prompt without error.
"dhoke" <dhoke....@east-shore.com> wrote in message
news:46cb08ee$1...@newsgroups.borland.com...
dhoke
The unresolved items reported in the link errors are all items that are
defined in our project source code, and are present, on both Machine A and
machine B. One is a global variable, the other three were (I think) all
methods of the same form class.
"dhoke" <dhoke....@east-shore.com> wrote in message
news:46cb08ee$1...@newsgroups.borland.com...
dhoke
This problem is apparently caused by the same path handling (or path problem
trigger) as a previous problem:
http://groups.google.com/groups/search?q=bds2006+related+questions+problem+search&qt_s=Search
I can reproduce machine B errors on machine A (with machine A's BDS
installation) if the build tree is in path aa, but linking succeeds if the
build tree is in path bb.
This has cost us somewhere between 2-3 developer days of productivity trying
to isolate this and find an acceptable way around it. And it still doesn't
seem to be completely deterministic as to what paths are OK, and what paths
are BAD, so we don't really know what might cause it to occur next.
We now have two totally different problem manifestations, apparently related
to the same tool bug. So when we encounter problems, do we look for them in
our code, or the supporting tools and environment????!!!!
If anyone can shed any light as to how we can avoid this in the future it
would be greatly appreciated!!!
We have observed builds succeeding/failing with the following path
differences (that I can currently recall):
...\trunk\... fails
...\trunk1547\... fails
...\trunk1601\... succeeds
...\trunk5\... fails
...\trunkqqq\... succeeds
...\trunk7\... fails
...\trunk7qqq\... succeeds
"dhoke" <dhoke....@east-shore.com> wrote in message
news:46cb08ee$1...@newsgroups.borland.com...
Lee Cantey
> If anyone can shed any light as to how we can avoid this in the future it
> would be greatly appreciated!!!
>
> We have observed builds succeeding/failing with the following path
> differences (that I can currently recall):
>
> ...\trunk\... fails
> ...\trunk1547\... fails
> ...\trunk1601\... succeeds
> ...\trunk5\... fails
> ...\trunkqqq\... succeeds
> ...\trunk7\... fails
> ...\trunk7qqq\... succeeds
I don't know of any reported problem that would seem to be related to
the issue you're seeing. If there's any way you could give me a
linkset that reproduces the problem I'd appreciate it and we could get
this resolved for you.
Regards,
Lee
dhoke
I fear that after I sanitize the project to a submittable state, the problem
will not be in evidence.
"Lee Cantey" <lca...@codegear.com> wrote in message
news:m2k5rmm...@serenity.inprise.com...
Helmut Giese
<dhoke....@east-shore.com> wrote:
>We have observed builds succeeding/failing with the following path
>differences (that I can currently recall):
>
>...\trunk\... fails
>...\trunk1547\... fails
>...\trunk1601\... succeeds
>...\trunk5\... fails
>...\trunkqqq\... succeeds
>...\trunk7\... fails
>...\trunk7qqq\... succeeds
FWIW I seem to remember that several years ago (using the then current
version of Builder) I had a vexing problem with path names which I
finally "decided" was due to the _length_ of the path - either the
overall length or maybe of specific sections.
No idea if this was the real reason, but changing the length of some
directory(ies) on the path made the problem go away.
Maybe this rings another bell with someone?
Best regards
Helmut Giese
dhoke
and a linkset with which I have been able to reproduce it has now been
provided to B/CG. Hopefully it will reproduce the problem for them as well.