Thanks for your extensive answer, I'm getting closer
to understand, or at least oversee this topic.
I've a two-pass test build with MinGW, and the exact
same executables were generated, except the .dll which
became a little bit smaller and indeed exported those
functions which we marked with HB_EXPORT. Anyhow now
it indeed doesn't seem make too much difference
(except much longer build-time), so I've left the one
pass build as default.
Also synced hbmk2 to not add -DHB_DYNDLL when win/gcc
compilers are used to generate .dll targets. I didn't
need to touch the Linux part. hbmk2 and GNU Make are
already in sync here, as HB_DYNDLL is not used
automatically in either of them.
With these, my questions are closed.
As for the IMPORT issue, which is a new one, would
it mean that "ideally" (to avoid current workarounds)
we'd also need different C compiler depending on
static or shared target Harbour executable? If this is
so, I'd rather vote to keep your current workarounds,
as they relieve us from dealing with the IMPORT issue,
and same object code stays good for both modes. If
we want to solve it though, I'll have to add HB_DYNDLL
definition for -shared mode executable targets.
Maybe it'd be better to have separate macros for these
two modes. HB_DYNEXP, HB_DYNIMP maybe. But I'm getting
a little bit lost again at this point :)
Brgds,
Viktor
The visibility attribute allows to reduce number of public symbols and
it works on most of platforms which supports ELF format though I
enabled
it only for Linux and used in my local builds. Maybe in the future
it will
be commonly used and we can make it default for all *nix builds.
Do we need these? When? Should we create a separate
-DHB_DYNLIB build for MinGW for any reason?
MinGW has a feature which allows to automatically add export attribute
to all public symbols if non of them has such attribute explicitly set
when DLL is created. If at least one attribute is exported then it's
automatically disabled so programmer choice has the highest priority
and only programmer decides which symbols should be exported.
We are using this functionality to create harbour.dll from object and
libraries created for non exported static builds. It allows us to
eliminate
one compilation phase but it's a hack which can cause some problems.
Code for dynamic libraries has to be relocatable. On some systems it
means
that it will have to be a little bit less optimal (slower) then pure
static
code. Usually if programmer wants to enable relocatable code he has
to use
-fpic or -fPIC GCC switch. Anyhow on some systems (CPUs) most of
generated
code is relocatable by default as long as some additional optimization
switches are not enabled. As I can see it happens in MinGW builds at
least
for x...@32. Here we do not use any -fpic/-fPIC switches and we can
create
fully functional harbour.dll. Anyhow it's possible that such
functionality
will be lost in the future or even now cannot be used with some non
default
optimization switches - I haven't make any deeper tests with current
MinGW
builds on Windows so I do not know. In general we should keep
support for
separate build phase which can be necessary to create shared library.
For sure it's necessary to use -fpic or -fPIC in most of *nixes except
Linux on x...@32 though even here some code constructions may force it.
Of course we can enable -fPIC as default switch (and we already does
it
for some platforms because we do not have separate compilation phase
for
shared libraries here) but it causes noticable performance reduction.
Depending on architecture from 0 (some CPUs can use only relocatable
code)
to 20%. On x86 machines it is between ~5-10%. In general clean build
for
shared library should export symbols and use -fPIC/-fpic switch.
In Windows there are two attributes: EXPORT and IMPORT.
The 1-st one causes that symbols are exported in public table which
later
can be accessed to create bindings between executable and DLLs. It
should
not effect directly generated code though indirectly it may interact
with
some compiler logic, i.e. some optimizations can be bound with
existence
of such attribute. IMPORT attribute has different meaning. It informs
compiler the symbol comes from external DLL or executable. It means
that
compiler has to access such symbol indirectly by dynamic symbol table
and cannot make optimizations which needs link time bindings and
offset
recalculations. It causes that slower code is generated but there is
not
other way. The faster optimal code simply cannot work. It's extremely
important for structures. Without valid IMPORT attribute their members
cannot be accessed from external DLLs. It means that the same header
files
should use EXPORT attribute when they are used to compiled base code
which
should be replaced by IMPORT attribute when they are used by
external DLL
code which want to use exported functions or structures. In fact for
simple
functions it will work even if header files contain EXPORT
attribute. But
for any constructions which needs offsets, f.e. structure members it
won't
and valid IMPORT attribute is strictly necessary - otherwise
compiler will
generate optimized code which cannot be used with dynamic DLL
bindings.
Looks that in the past this knowledge was not known for [x]Harbour
windows
developers and instead of fixing attributes in header files as
workaround
for accessing some structures like hb_stack or hb_set functions like
hb_GetSetStructPtr() or hb_stack(). It was working but it was the less
efficient way. The same effect can be reached by using indirect
pointer
items like and it was the reason why I added to xHarbour:
HB_SET_STRUCT * hb_set_ptr = &hb_set
and:
HB_STACK * hb_stack_ptr = &hb_stack;
Using them instead hb_set and hb_stack directly effectively resolves
the
problem forcing the code like for structures declared with IMPORT
attribute.
Anyhow it was also hack and the valid solution is introducing to
header
files an option which allow to switch IMPORT/EXPORT attribute at
least for
non-function symbols.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
