hbmk2 and ms linker link order issue

[Lorenzo Fiorini]

I have an hbmk2 project with a modified FiveWin's classes lib that
should be used before the original one.

VC 2010 ms linker uses objects from original lib instead from the
modified one, even if libpaths are correct and the modified lib is
listed before the original one ( note that bcc works as expected but I
cannot check with mingw ).

hbmk2 -trace output seems ok according to the doc and using the
VERBOSE output I could manually fix the dependencies but is difficult
to be sure that every dependence is respected and using
/INCREMENTAL:NO doesn't help.

Any idea?

best regards,
Lorenzo

[Viktor Szakáts]

Hi Lorenzo,

It'd be worth verifying if the replacement object (or objects) 

from the replacement lib contains the exact same set of 

public symbols as the original one. If not, it may create 

such problem.

[ similar used to happen when users are trying to override 

Harbour's getsys object with their own one, directly copied 

from a Clipper 5.2 project, while Harbour needs one from 

5.3 (or from Harbour itself) to publish all public symbols, 

published by Harbour. ]

Viktor

[Lorenzo Fiorini]

On Mon, Jan 24, 2011 at 12:55 PM, Viktor Szakáts <harbo...@syenar.hu> wrote:

> It'd be worth verifying if the replacement object (or objects)
> from the replacement lib contains the exact same set of
> public symbols as the original one. If not, it may create
> such problem.

Yes they are exactly the same prg with "internal" modifications like
add members, methods and change the way to calculate the row,col
position.
Note that EXACTLY the same code build correctly with bcc simply
changing the library names in fwh.hbc and setting the path.
So it seems to be the different linker strategy to resolve functions.

best regards,
Lorenzo

[Viktor Szakáts]

> It'd be worth verifying if the replacement object (or objects)
> from the replacement lib contains the exact same set of
> public symbols as the original one. If not, it may create
> such problem.

Yes they are exactly the same prg with "internal" modifications like
add members, methods and change the way to calculate the row,col
position. 

 

Note that EXACTLY the same code build correctly with bcc simply
changing the library names in fwh.hbc and setting the path.

It doesn't mean anything. Linkers work differently, bcc being 

among the more (most) "allowing" ones (pbly that's one reason 

why some users prefer it). This property is nice at first, but it makes 

bcc very unpredictable and it can hide real problems.

So maybe it's something else, I can't guess more given the 

information available. Pbly some small sample and hbmk2 -trace 

outputs could give more clue.

Maybe you should try including the modified object as plain 

object (or direct source) instead of adding an additional copy 

of fwh lib which contains the modified object. This method 

works all the time using getsys object. All linkers I know will 

put such objects in front of the list of libs.

Viktor

[Lorenzo Fiorini]

On Mon, Jan 24, 2011 at 1:35 PM, Viktor Szakáts <harbo...@syenar.hu> wrote:

> It doesn't mean anything. Linkers work differently, bcc being
> among the more (most) "allowing" ones (pbly that's one reason
> why some users prefer it). This property is nice at first, but it makes
> bcc very unpredictable and it can hide real problems.

In fact when I used mingw I found two function with the same name in
different sources.

However it seems I've found a working solution adding some
dependencies in the modified lib and swapping the lib position.
hbmk2's trace + /VERBOSE gives a very detailed information so at least
I found a way to debug.

Many thanks for the attention.

best regards,
Lorenzo

[Viktor Szakáts]

> It doesn't mean anything. Linkers work differently, bcc being
> among the more (most) "allowing" ones (pbly that's one reason
> why some users prefer it). This property is nice at first, but it makes
> bcc very unpredictable and it can hide real problems.

In fact when I used mingw I found two function with the same name in
different sources.

That's sign of two objects colliding with non-indentical 

public interfaces.

However it seems I've found a working solution adding some
dependencies in the modified lib and swapping the lib position.
hbmk2's trace + /VERBOSE gives a very detailed information so at least
I found a way to debug.

Yes, I was just about to propose to add a puller symbol.

Many thanks for the attention.

You're welcome! Good it's resolved.

Viktor