use of dynamic dll with hbmk2

[Antonino Perricone]

Hello, 

I am doing some tests with dll in harbour.

my code can be condensed in:

function Main()

    local pDll  := HB_LibLoad( "pcdll1.dll" )

    ? 'pDll ', pDll

    if type( "TEST_DLL()" ) == 'UI'

        ? "linked"

    else

        ? "not work"

    endif

I see that if I add the -shared option to hbmk2 it works correctly.

If I don't add .-shared, the type are not linked correctly.

I see also that the executable with .shared is considerably smaller (79K instead of 662K), but If I try to use a library some method are missing, like hb_gcGripGet and hb_gcGripDrop ...

What mean the shared option? I will need to include some extra dll to final installation? how can I fix the unsolved references?

Thanks,

Antonino

[Diego Fazio]

Hi, Antonino. Maybe here is your answer...

https://groups.google.com/forum/#!topic/harbour-users/0NoR4k_KeRk

Diego.

[Antonino Perricone]

Hi, that is the topic I started from.

But does not solve my problem.

I am using FiveWin, and looks like the function are undefined for fivehc32.lib but not for my application...

Thanks.

Antonino

[xamm-inf]

Try changing order to libs in your .mak (or similar) link file.

[Antonino Perricone]

It is a good test to do... but how can I do it with hbmk2? 

It handles the standard libs how it wants

[xamm-inf]

Ah.... hbmk2... 

Try, please, a .prg mini sample with a litte .mak without hbmk2.

[Klas Engwall]

Hi Antonino,

All Harbour core functions are included in harbour<version>.dll and are
automatically found if that dll is in the path. No contrib functions or
3rd party functions exist in that dll, so you have to REQUEST each and
every one that you need at the top of the main application and declare
the same functions DYNAMIC in each of your own dlls. That will link them
to the main exe so your dlls know where to find them. Did you create a
header file for that purpose like I suggested in my second message in
that old thread?

Also, for the main exe specify -hbexe and -shared, and for your dlls
specify -hbdynvm -shared and -nohblib

You may also have to specify hbc files for contribs you use (in the hbp
files for your dlls) in case the dll sources need the header files of
those contribs.

You mentioned a 79 KB size for the exe file, and that is normal if no
contribs are used, but since all contrib functions have to be linked
into the main exe, it will grow quickly. If 79 KB is your final file
size, then I suspect that no contribs have been linked.

BTW, never link any contribs or 3rd party libs to the dlls. If you do
that with two dlls and both are active at the same time there will be chaos.

Regards,
Klas

[Antonino Perricone]

Thanks Klas for you illumining post,  I tried including harbour.hbx in both dll and main specifying __HBEXTERN__HARBOUR__REQUEST on main.

My error is:

main.c

fivehc32.lib(ACTX.obj) : error LNK2019: riferimento al simbolo esterno _hb_gcGripGet non risolto nella funzione _HB_FUN_CREATEACTIVEX

fivehc32.lib(ACTX.obj) : error LNK2019: riferimento al simbolo esterno _hb_gcGripDrop non risolto nella funzione _HB_FUN_ACTXEND

so looks like a c level problem.

If I use -ldflag=/force to force the linker to create the exe, it works, but I prefer remove the error, if it is possible.

Regards,
Antonino

[Klas Engwall]

Hi Antonino,

> Thanks Klas for you illumining post,  I tried including harbour.hbx in
> both dll and main specifying __HBEXTERN__HARBOUR__REQUEST on main.
> My error is:
> |
> main.c
> fivehc32.lib(ACTX.obj) : error LNK2019: riferimento al simbolo esterno
> _hb_gcGripGet non risolto nella funzione _HB_FUN_CREATEACTIVEX
> fivehc32.lib(ACTX.obj) : error LNK2019: riferimento al simbolo esterno
> _hb_gcGripDrop non risolto nella funzione _HB_FUN_ACTXEND
> |
> so looks like a c level problem.

> If I use *-ldflag=/force *to force the linker to create the exe, it

> works, but I prefer remove the error, if it is possible.

I have never included harbour.hbx - it should not be needed since
everything that is referenced in it should already be included in
harbour<version>.dll

Have you checked that your harbour<version>.dll is not damaged?

Does by any chance FiveWin have its own garbage collector that resides
in a module that is not linked?

Can you post your hbp file for the exe file? Which Harbour version do
you use? 3.2 or 3.4?

Regards,
Klas

[Antonino Perricone]

Thanks Klas for your interesting.

Here an hbp that reproduce the problem:

-incpath=${FWH_INSTALL}\INCLUDE;

mini.prg

xhb.hbc

hbziparc.hbc

-L${FWH_INSTALL}\LIB

-lFiveH32

-lFiveHC32

-ldflag=/NODEFAULTLIB:libcmt

-lVersion

-lOleDlg

-lGdiplus

-ldflag=/map

-shared
-ldflag=/force

without shared it compile without problem.

I would like to remove the last line 

With the last 2 line the exe is 2486K, without is 3597Kb

mini.prg is

#include <fivewin.ch>

function Main()

    ? "hello"

The harbour I use is from git then build with win-make, the version 3.2

I use two pc, and the problem is in both, but in both I did the same setup

[Klas Engwall]

Hi Antonino,

How about starting with a minimal hbp file without all the extras? Then
add just the fivewin libs? Would that make any difference?

You are not using MinGW for this, are you? Does my sample from the 2011
thread compile correctly "as is"? What happens if you add your extra
options, one by one, to my hbp file?

Regards,
Klas

[Antonino Perricone]

FiveWin alone does not compile, it needs all other libs I wrote...

The sample "as is" works great.

I am using  Visual studio 2017 

[Klas Engwall]

Hi Antonino,

> FiveWin alone does not compile, it needs all other libs I wrote...
> The sample "as is" works great.
> I am using  Visual studio 2017

So, maybe it is time to check with Antonio Linares if he has any
experience with combining his product with pcode dlls. For me it is just
weird that the garbage collector cannot be found.

Regards,
Klas