Problem getting RDDADS to work with mingw
dougwoodrow
Massimo Belgrano
win-make clean install
Here at the end i found ace32.lib copyed to libace32.a
and my ads app works fine
post you sample prg/hbp for try
2011/4/21 dougwoodrow <dougw...@gmail.com>:
> I'm probably doing something wrong, but I can't seem to get the rddads
> library built correctly.
> I'm using the Advantage v8.10 client SDK if that matters:
> set path=c:\HbP\comp\mingw\bin;%PATH%
> set HB_WITH_ADS=c:\HbP\acesdk\ADS810
> win-make
> COPY ace32.lib libace32.a
> Is this manual process still necessary?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
--
Massimo Belgrano
dougwoodrow
> IMO you must start from
> win-make clean install
the different options are for)
> Here at the end i found ace32.lib copyed to libace32.a
> and my ads app works fine
there somewhere I can obtain just the lib utility from MSVC?
Massimo Belgrano
you need in c::\HbP\acesdk\ADS810
from c:\program file\extend system\advantage 8.1\acesdk
afaik in web is follow
http://devzone.advantagedatabase.com/dz/content.aspx?key=20&Release=10
2011/4/21 dougwoodrow <dougw...@gmail.com>:
> On Apr 21, 9:43 am, Massimo Belgrano <mbelgr...@deltain.it> wrote:
>
> And how did you create ace32.lib? I don't have MSVC installed, is
> there somewhere I can obtain just the lib utility from MSVC?
>
--
Massimo Belgrano
dougwoodrow
> ace32 lib is part of ace client from sybase
> you need in c::\HbP\acesdk\ADS810
> from c:\program file\extend system\advantage 8.1\acesdk
>
> afaik in web is followhttp://devzone.advantagedatabase.com/dz/content.aspx?key=20&Release=10
for some reason ace32.lib was missing from my old acesdk folder.
You're right, I just renamed it to libace32.a and put it in the lib
folder and now the application links without errors and connects to
the Advantage server. Many thanks!
Massimo Belgrano
version that you use on client
2011/4/21 dougwoodrow <dougw...@gmail.com>:
Viktor Szakáts
This issue is normally taken care of by the default
build process. Make sure that ADS directory is a
complete vanilla one, and if you use 'make' with
'install' you should use 'HB_INSTALL_IMPLIB=yes'.
Viktor
On Apr 21, 11:48 am, Massimo Belgrano <mbelgr...@deltain.it> wrote:
> Remember that you need update ads version to server to an ogual/upper
> version that you use on client
>
dougwoodrow
Remember that you need update ads version to server to an ogual/upper
version that you use on client
dougwoodrow
This issue is normally taken care of by the default
build process. Make sure that ADS directory is a
complete vanilla one, and if you use 'make' with
'install' you should use 'HB_INSTALL_IMPLIB=yes'.
dougwoodrow
ace32, thank you!
The exe size of my application is 2.3MB with Harbour/mingw whereas it
was 1.5MB when built with xHarbour/bcc, and 420KB for the DOS
version. Is this because there are lots of static libraries
automatically linked in? Is there any simple way to reduce the exe
size?
Viktor Szakáts
1) You don't need to use 'install' at all, in order to use Harbour.
The build works without it just as well, and this is the most
easy way to build and use Harbour.
2) Installing implibs is considered dangerous because the implibs
are tied to the .dll versions the build process found in the
local
computer while doing the build. So, those installed implibs
wouldn't
necessarily work when moved to other systems with different
versions of these .dlls. IOW it would collide with the major
point
of 'install', that is to create binaries which can be
distributed.
For example the nightly and release binary builds never contain
implibs for this very reason.
Viktor
Viktor Szakáts
Please notice that mingw version runs much faster and
there is always a balance between size and speed. BCC is
slow and small, while mingw is slightly bigger but much
faster.
You can also use -compr=max hbmk2 option to compress
it and save disk space. You'll need to have upx installed
in PATH.
Viktor
dougwoodrow
(and thanks for the explanation about implibs).
On Apr 21, 5:34 pm, Viktor Szakáts <harbour...@syenar.hu> wrote:
> On Apr 21, 1:53 pm, dougwoodrow <dougwood...@gmail.com> wrote:
> > The exe size of my application is 2.3MB with Harbour/mingw whereas it
> > was 1.5MB when built with xHarbour/bcc, and 420KB for the DOS
> > version. Is this because there are lots of static libraries
> > automatically linked in? Is there any simple way to reduce the exe
> > size?
>
> -strip hbmk2 option.
> Please notice that mingw version runs much faster and
> there is always a balance between size and speed. BCC is
> slow and small, while mingw is slightly bigger but much
> faster.
> You can also use -compr=max hbmk2 option to compress
> it and save disk space. You'll need to have upx installed
> in PATH.
disadvantages to using UPX?
Viktor Szakáts
On Apr 21, 7:34 pm, dougwoodrow <dougwood...@gmail.com> wrote:
> Hi Viktor
> (and thanks for the explanation about implibs).
compression and if it runs and finds its resources, it's
okay. I had never experienced problem with Harbour apps,
that's why it got dedicated support in hbmk2.
I saw reports on the net about virus checkers occasionally
false alarming on compressed exes, this is something
to keep in mind with upx too.
Plus, but this starts to be upx forum topic, compressed
exes cannot be mapped to memory, so it has some
overhead because of that, plus there is a short time
to uncompress the exe at startup. Nothing unbearable,
but it may be concern for some.
For more detailed answer check upx forums and docs.
Viktor
dougwoodrow
> > > You can also use -compr=max hbmk2 option to compress
> > > it and save disk space. You'll need to have upx installed
> > > in PATH.
>
> > Interesting utility - exe now down to 672KB. Are there any
> > disadvantages to using UPX?
>
> My short answer is no. Make sure to run your app after
> compression and if it runs and finds its resources, it's
> okay. I had never experienced problem with Harbour apps,
> that's why it got dedicated support in hbmk2.
>
> I saw reports on the net about virus checkers occasionally
> false alarming on compressed exes, this is something
> to keep in mind with upx too.
>
> Plus, but this starts to be upx forum topic, compressed
> exes cannot be mapped to memory, so it has some
> overhead because of that, plus there is a short time
> to uncompress the exe at startup. Nothing unbearable,
> but it may be concern for some.
>
> For more detailed answer check upx forums and docs.
Przemysław Czerpak
Hi,
> > Interesting utility - exe now down to 672KB. Are there any
> > disadvantages to using UPX?
> My short answer is no. Make sure to run your app after
> compression and if it runs and finds its resources, it's
> okay. I had never experienced problem with Harbour apps,
> that's why it got dedicated support in hbmk2.
>
> I saw reports on the net about virus checkers occasionally
> false alarming on compressed exes, this is something
> to keep in mind with upx too.
>
> Plus, but this starts to be upx forum topic, compressed
> exes cannot be mapped to memory, so it has some
> overhead because of that, plus there is a short time
> to uncompress the exe at startup. Nothing unbearable,
> but it may be concern for some.
I'll only add that missing memory mapping is real problem only
in systems which can really exploit such functionality, i.e. in
Linux when system detects that new application or shared library
is loaded and other one with the same i-node is already loaded/
executed then it simply shares existing code and readonly data
pages with new application without loading it at all. In some
cases it's also possible then it will share writable data pages
using copy on write flag. All such things are lost when you compress
executable files using some external to kernel compression methods
like UPX. So if you are writing server applications which can be
executed locally by many clients simultaneously then you should not
compressed them to avoid unnecessary speed overhead and memory
consumption. Otherwise use UPX.
Returning to code size generated by C compilers. One of the most
effective speed improvement mechanism is automatic code inlining
and then optimizing whole function body when it's quite well
flatten. It greatly improves many other internal compile time
optimizations because without function calls compiler can analyze
all possible operations and does not have to use pessimistic
scenario that contents of some memory areas is changed by some
other code executed from called functions an d can reuse data already
loaded to CPU registers without accessing physical memory.
Additionally it does not have to worry about CPU registers which
are not saved during function call in given C ABI for given platform
and can nicely reuse them. In summary it gives really good performance
optimization with one limitation: such optimization is done at compile
time and autoinlining can be used only for currently compiled file.
Anyhow it gives such noticeable speed improvement that modern compilers
try to extend it for different files (compile time modules).
The newest GCC versions begin to move final optimization to linking
phase - it means that compiler generates meta code which is stored
in object files (.o/.obj) and then linker extracts this meta code to
make final autoinlining and repeat all possible optimizations. If you
are interesting in details then look for link time IPO (inter procedural
optimizations) and -O4 option in GCC.
Compilers like BCC does not make such optimizations at all - even such
simple things like:
memcpy( dst, src, 4 );
are not automatically replaced by this compiler with
* ( __int32 * ) ( dst ) = * ( __int32 * ) ( src );
what can be compiled to single
lmov [dst],[src]
machine command but function call is generated. This compiler is still
in 80 years of last century. The final code is usually smaller but also
much more slower.
Anyhow using GCC if code size or compilation speed is very important then
you can change optimization switches, i.e. you may try to use -Os instead
of default in Harbour -O3. Just simply set
set HB_USER_CFLAGS=-Os
and rebuild whole Harbour core code. Then relink your programs and compare
final size.
For your own code the C compiler flags are less important (we are not
using link time IPO yet in default configuration) so you can leave it
as is. In core code we make some special trick to enable IPO for nearly
whole HVM code and it gives really nice results even without LT-IPO.
BTW Harbour compiler internally generates from .prg code .c files.
In -gc[0-2] modes (-gc[0-3] is Harbour compiler switch) it generates
PCODE for whole functions encapsulated in very small C preamble and
postamble. In -gc3 mode it generates real C code which calls HVM
functions directly. The last version is a little bit faster (~10
to ~25 %) but needs much more memory for code. In practice only
the code generated for -gc3 can be optimized by C compiler and
linker with LT-IPO. For -gc[0-2] there is no place for some advances
optimizations (for -gc0, -gc1 and -gc2 exactly the same code is generated
and the difference is only in human readability but not for C compilers).
If you are interesting in details and you want to see with your own
eyes C code generated by Harbour compiler then you can use -hbraw
option with hbmk2.
best regards,
Przemek
ps. In tests/speedtst.prg you will find simply speed test code which
you can use to compare speed differences in cases (also with other xbase
compatible compilers).
For Harbour if you want to reach optimal results use:
hbmk2 -w -kmo -l -gc2 -static -st speedtst
dougwoodrow
>
> I'll only add that missing memory mapping is real problem only
> in systems which can really exploit such functionality,
> executed locally by many clients simultaneously then you should not
> compressed them to avoid unnecessary speed overhead and memory
> consumption. Otherwise use UPX.
running the same application under Windows terminal sessions?
Viktor Szakáts
> > in systems which can really exploit such functionality,
> [...]
> > So if you are writing server applications which can be
> > executed locally by many clients simultaneously then you should not
> > compressed them to avoid unnecessary speed overhead and memory
> > consumption. Otherwise use UPX.
>
> Interesting stuff... any idea what the situation is with 10 users
> running the same application under Windows terminal sessions?
Viktor
dougwoodrow
> > any idea what the situation is with 10 users
> > running the same application under Windows terminal sessions?
>
> I wouldn't, in this scenario.