Is the proceding defined?
Read the ChangeLog.
You do not have to even use it.
Should I test it already?
I already tested it but as I said you do not have to use it at all.
I'll surely try HRB files as you suggested, but first I want to see how it
works with pCode DLLs.
Thank you very mu
On Sun, 14 Feb 2010, Leandro Damasio wrote:
Hi,
> >>bpp.o -lhbnortl -lhbcommon -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32
> >>/mingw/lib/libmingw32.a(main.o):main.c:(.text+0xd2): undefined
> >>reference to `winm...@16'
> >>collect2: ld returned 1 exit status
> >>mingw32-make[3]: *** [hbpp.ex
There is an error when I try to recompile Harbour core with -DHB_DYNLIB.
Apparently the problem is about hbpp.exe
See the error below:
...
gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -march=i586
-mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -DHB_DYNLIB -ohbpp.o -c
../../../hbpp
Hello Przemek
>It will work but I do not understand how it's possible to call
>function by macro knowing it's name when macro value is created
>but in other context you do not know this name. Your above
>description does not make any sense or you simply forgot to say
>about some important condit
On Thu, 11 Feb 2010, Leandro Damasio wrote:
Hi,
> >It will work but I do not understand how it's possible to call
> >function by macro knowing it's name when macro value is created
> >but in other context you do not know this name. Your above
> >description does not make any sense or you simply f
>But in the .prg code used for EXE file when you are calling
>functions which do not exist in it and are loaded dynamically
>then all such functions should be declared as DYNAMIC otherwise
>you will have link time error (function does not exist).
In my case of use the functions in the DLL are call
On Wed, 10 Feb 2010, 2D Info - Leandro Damasio wrote:
Hi,
> >But in the .prg code used for EXE file when you are calling
> >functions which do not exist in it and are loaded dynamically
> >then all such functions should be declared as DYNAMIC otherwise
> >you will have link time error (function d
Hi Przemek
But in the .prg code used for EXE file when you are calling
functions which do not exist in it and are loaded dynamically
then all such functions should be declared as DYNAMIC otherwise
you will have link time error (function does not exist).
In my case of use the functions in the D
On Wed, 10 Feb 2010, 2D Info - Leandro Damasio wrote:
Hi,
> >-implib for -hbexe is okay, I'll commit it. For the other,
> >I'd prefer to suggest -ldflag=--export-all-symbols until we find
> >at least one more target which supports this option.
> Probably I've lost you, but does this flag (--expor
-implib for -hbexe is okay, I'll commit it. For the other,
I'd prefer to suggest -ldflag=--export-all-symbols until we find
at least one more target which supports this option.
Probably I've lost you, but does this flag (--export-all-symbols) supress
the need of using DYNAMIC clause on exe prog
Hi,
>>> Interesting, Important for me feature you are calling bug :)
>>> I hope that in the future we will not lost possibilities to
>>> build Harbour with and without exported symbols using some
>>> optional settings.
>> I wonder: when could this be useful?
>
> I.e. to not use 'hbmaindllp' at al
On Wed, 10 Feb 2010, Szak�ts Viktor wrote:
Hi,
> > Interesting, Important for me feature you are calling bug :)
> > I hope that in the future we will not lost possibilities to
> > build Harbour with and without exported symbols using some
> > optional settings.
> I wonder: when could this be usef
On Wed, 10 Feb 2010, Szak�ts Viktor wrote:
Hi Viktor,
> >> 1. -implib in MinGW and OpenWatcom builds uses "{OI}" as import
> >> library name. In BCC builds it works OK. I haven't tested other
> >> builds
> > Can you fix it?
> Yes, sorry, I missed the fact this was a bug to look at.
> BCC work
Hi Przemek,
> Hi Viktor,
>
>> 1. -implib in MinGW and OpenWatcom builds uses "{OI}" as import
>> library name. In BCC builds it works OK. I haven't tested other
>> builds
>
> Can you fix it?
Yes, sorry, I missed the fact this was a bug to look at.
BCC works because there the name is genera
>>> I though about it but in practice it means that it's necessary to create
>>> separate library which is not included by harbour*.dll or hack make files
>>> to exclude single file from harbour shared library. Personally I do not
>>> like such hacks because sooner or later they are exploited by st
On Tue, 09 Feb 2010, Przemysław Czerpak wrote:
Hi Viktor,
> 1. -implib in MinGW and OpenWatcom builds uses "{OI}" as import
>library name. In BCC builds it works OK. I haven't tested other
>builds
Can you fix it?
best regards,
Przemek
___
Harb
On Wed, 10 Feb 2010, Szak�ts Viktor wrote:
Hi,
> > I though about it but in practice it means that it's necessary to create
> > separate library which is not included by harbour*.dll or hack make files
> > to exclude single file from harbour shared library. Personally I do not
> > like such hacks
Hi,
>> Another idea, and this looks the best so far. Why not introduce
>> a symbol which can be REQUESTed from app code, if someone wants
>> to enable pcode loading feature?
>> F.e.
>> REQUEST HB_LIB (or HB_LIBDYN...)
>> This would pull above code from a separate .c file, which .c file
>> wou
On Wed, 10 Feb 2010, Szak�ts Viktor wrote:
Hi,
> Another idea, and this looks the best so far. Why not introduce
> a symbol which can be REQUESTed from app code, if someone wants
> to enable pcode loading feature?
> F.e.
>REQUEST HB_LIB (or HB_LIBDYN...)
> This would pull above code from a
Hi,
Isn't it a solution if we move HB_LIBLOAD() to a separate
.c file along with above trigger code, and in this way,
if an executable uses this functionality, above stub is
always included?
>>> No because it will disable autoexport functionality in MinGW
>>> builds.
>> Hm,
>#include "hbapi.h"
>HB_EXPORT_ATTR PHB_FUNC dll_hb_vmProcAddress( const char * szFuncName )
>{
> return hb_vmProcAddress( szFuncName );
>}
>> I see. Can't it be added unconditionally for all Windows .exes?
>> Is there any downside?
>
> It enables symbol e
On Wed, 10 Feb 2010, Szak�ts Viktor wrote:
Hi,
> >> Isn't it a solution if we move HB_LIBLOAD() to a separate
> >> .c file along with above trigger code, and in this way,
> >> if an executable uses this functionality, above stub is
> >> always included?
> > No because it will disable autoexpor
> On Tue, 09 Feb 2010, Szak�ts Viktor wrote:
>> Isn't it a solution if we move HB_LIBLOAD() to a separate
>> .c file along with above trigger code, and in this way,
>> if an executable uses this functionality, above stub is
>> always included?
>
> No because it will disable autoexport functiona
On Tue, 09 Feb 2010, Szak�ts Viktor wrote:
> Isn't it a solution if we move HB_LIBLOAD() to a separate
> .c file along with above trigger code, and in this way,
> if an executable uses this functionality, above stub is
> always included?
No because it will disable autoexport functionality in Mi
Hi
We only have to choose name for this new option.
My propositions: -hasdyn or -usedyn -expdyn
Sorry but I'm the last person for such jobs but I believe that other
users can help us.
-usedyn sounds the most intuitive for me
Regards
Leandro
___
You are right. It's side effect of code added to exclude hbpp_dyn.obj
from DLL. I'll replace it with other solution. Anyhow probably today
we add support for using PCODE DLLs with standard static builds so
you can wait a while for it.
Ok Przemek
Thanks
Brgds
Leandro
___
>#include "hbapi.h"
>HB_EXPORT_ATTR PHB_FUNC dll_hb_vmProcAddress( const char * szFuncName )
>{
> return hb_vmProcAddress( szFuncName );
>}
>> I see. Can't it be added unconditionally for all Windows .exes?
>> Is there any downside?
>
> It enables symbol e
On Tue, 09 Feb 2010, Szak�ts Viktor wrote:
Hi,
> >>> #include "hbapi.h"
> >>> HB_EXPORT_ATTR PHB_FUNC dll_hb_vmProcAddress( const char * szFuncName
> >>> )
> >>> {
> >>>return hb_vmProcAddress( szFuncName );
> >>> }
> I see. Can't it be added unconditionally for all Windo
On Tue, 09 Feb 2010, 2D Info - Leandro Damasio wrote:
Hi,
> There is an error when I try to recompile Harbour core with -DHB_DYNLIB.
> Apparently the problem is about hbpp.exe
> See the error below:
> ...
> gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer
> -march=i586
> -mtu
>>> 7. It's necessary to add to HBMK2 link time option which add this
>>> code to final binaries:
>>> #include "hbapi.h"
>>> HB_EXPORT_ATTR PHB_FUNC dll_hb_vmProcAddress( const char * szFuncName )
>>> {
>>>return hb_vmProcAddress( szFuncName );
>>> }
>>> I'll update Harbou
On Tue, 09 Feb 2010, Szak�ts Viktor wrote:
Hi Viktor,
> > 2. -hbdyn should automatically disable all static harbour
> > libraries (-nohblib) but it should be possible to enable
> > shared harbour library using -*shared option.
[...]
> I'll make -nohblib default when using -hbdyn, this also
>
Hi Przemek,
> 2. -hbdyn should automatically disable all static harbour
> libraries (-nohblib) but it should be possible to enable
> shared harbour library using -*shared option.
> I do not see any normal situation when harbour static libraries
> can be linked with PCODE shared library. It
On Tue, 09 Feb 2010, Szak�ts Viktor wrote:
Hi,
> Minor note: -cflag=-DHB_DYNLIB is automatically enabled for non-mingw
> compilers when -hbdyn is used, so it's not necessary to add it manually.
Thank you for the information.
> I believe the rest of this nice description should definitely go in
Hi Przemek
If you are using statically linked application then it's necessary
to recompile Harbour using with HB_DYNLIB macro to force exporting
hb_vmProcessSymbols() and hb_vmExecute() functions. You can make it
by setting HB_USER_CFLAGS envvar, i.e.:
set HB_USER_CFLAGS=-DHB_DYNLIB
before c
On Tue, 09 Feb 2010, Szak�ts Viktor wrote:
> Rereading it with somewhat fresher mind, probably I didn't
> see it correctly and such pcode dll can have other dlls it
> depends on.
Yes it is. And MinGW can nicely work with it so it's not necessary
to add other libraries to linked library list. It'
>>> Now the only thing I'm still interested in, is what
>>> are the advantage of pcode-.dlls over .hrb files?
>>> [ I can only cite inclusion of .c functions. ]
>>
>> Yes, mixed PRG and C code is probably the only one real feature.
>> Probably it's mostly important for 3-rd party extensions which
Very good Viktor!
This text will be really very helpfull to many people!
Brgds
Leandro
--
From: "Viktor Szakáts"
Sent: Monday, February 08, 2010 8:27 PM
To: "Harbour Project Main Developer List."
Subject: Re: [Harbour]
Hi Przemek!
I know what you did and why. The same will work also in Harbour
if you use exactly the same C compiler and linker. Anyhow it's
really dirty hack and the worse thing you could do.
Believe me do if you would know all internal details of such
hack with all possible problems and how many
Hi Przemek,
> to create PCODE dll simply use:
>
> hbmk2 -shared -strip -hbdyn dllcode.prg -n -w -es2
>
> and dllcode.dll is generated, if you are using other then MinGW C
> compiler then you should add -cflag=-DHB_DYNLIB (to force exporting
> public functions inside .prg code - only
Hi Przemek
I agree though I do not now if I'm right person to describe it
in INSTALL. For shared binaries using harbour*.dll there is
no problem at all and it's enough to link PCODE dll with harbour*.dll.
The problem is only with binaries which have HVM linked with static
part of application. In
On Mon, 08 Feb 2010, Szak�ts Viktor wrote:
Hi Viktor,
> > Probably to make it easier for users we can add small option to hbmk2
> > which will attach to final code exported wrappers to hb_vmProcessSymbols()
> > and hb_vmExecute() or single function which can be used to extract
> > addresses of ot
On Mon, 08 Feb 2010, 2D Info - Leandro Damasio wrote:
Hi,
> I don't know if I reach the point you are talking about, but in the
> xHarbour scenario I mentioned before apparently it wasn't needed to
> resolve all the references to any functions statically linked to the
> host executable, because t
Hi Przemek,
>> If it works using current tools, it's nice, and we probably
>> have to do only those steps you mention to make it easily
>> available for users. And document it. F.e. in INSTALL (if
>> the end result is elegant or simple), or a separate document
>> if the size of the topic deser
Hi Leandro,
On 2010 Feb 8, at 21:43, 2D Info - Leandro Damasio wrote:
> Hello Viktor
>
>> I hope someone can answer these, but until then I suggest
>> to lookup past messages, there has been _lots_ of detailed
>> talk about .hrb files, even recently. You can start by
>> looking up HB_HRB*() func
On Mon, 08 Feb 2010, Szak�ts Viktor wrote:
Hi Viktor,
> If it works using current tools, it's nice, and we probably
> have to do only those steps you mention to make it easily
> available for users. And document it. F.e. in INSTALL (if
> the end result is elegant or simple), or a separate docu
Hello Viktor
I hope someone can answer these, but until then I suggest
to lookup past messages, there has been _lots_ of detailed
talk about .hrb files, even recently. You can start by
looking up HB_HRB*() functions in ChangeLog and find examples
in source tree.
Thanks a lot. I'll follow your
Hi
I was creating them without any problems and from time to
time I made such tests together with HRB support.
As long as some of recent modification did not seriously
break sth then it should work without any problem.
The most important rule which users have to always remember:
it's illegal to
Hi,
On 2010 Feb 8, at 15:56, 2D Info - Leandro Damasio wrote:
> Hi Viktor
>
>> Sorry but I know nothing about pcode .dlls, hence
>> there is no support for it in hbmk2 (yet?). I can't
>> recall anyone doing any tests with this (besides me
>> a while back, but without any results)
>>
>
> If you
Hi Przemek,
>> Sorry but I know nothing about pcode .dlls, hence
>> there is no support for it in hbmk2 (yet?). I can't
>> recall anyone doing any tests with this (besides me
>> a while back, but without any results)
>
> I was creating them without any problems and from time to
> time I made s
On Mon, 08 Feb 2010, Szak�ts Viktor wrote:
Hi,
> Sorry but I know nothing about pcode .dlls, hence
> there is no support for it in hbmk2 (yet?). I can't
> recall anyone doing any tests with this (besides me
> a while back, but without any results)
I was creating them without any problems and
m: "Viktor Szakáts"
Sent: Monday, February 08, 2010 8:42 AM
To: "Harbour Project Main Developer List."
Subject: Re: [Harbour] How to build and use pCode DLL with hbmk2
Hi Leandro,
Sorry but I know nothing about pcode .dlls, hence
there is no support for it in hbmk2 (yet?
Hi Leandro,
Sorry but I know nothing about pcode .dlls, hence
there is no support for it in hbmk2 (yet?). I can't
recall anyone doing any tests with this (besides me
a while back, but without any results)
To do anything in this regard, first I should see
how pcode .dlls are supposed to work,
52 matches
Mail list logo
