On Sun, Feb 22, 2009 at 10:23 AM, Lorenzo Fiorini <[email protected] > wrote:
> On Sun, Feb 22, 2009 at 9:41 AM, Viktor Szakáts <[email protected]> > wrote: > > > It's easy to do even with static linking. I can add an hbmk2 switch > > to link all supported on platform core GTs, if that helps. (-allgt) > > No problem, I just think that since we do create harbour shared libs, > harbour's utils should use them. Not for platforms/install scenarios where this makes life just difficult, and away from general expected behaviour. We may add options to override platform defaults for builds. And the dll way could be a preferred solution for those who wish to put up with installers, modifying system settings writing into system dirs, but there is the other part of the world who wish to keep their system clean from these, with the cost of a few MBs more downloaded. I've been chasing a local Trac problem for about 1.5 years with all the arsenal of tools put into action, until I've finally found that it was a .dll hell problem between Apache and Subversion or Python picking up different slightly APR libs from different dirs. The error came down the path in the form of a strange Trac message and no access to SVN repository, with no obvious ways of resolution or any usable documentation found. We should IMO try not to make this situation any worse with Harbour. > It's a way to test the shared support and helps to find errors like > the one we found with hbgd. It's a pretty rare type of error, which is caught by building even a static executable (doubly defined symbols are always reported), so to cripple all our tools for that reason seems a little overkill, particularly for final users. BTW, however I detest .dlls, I'm working on GNU-make support for .dlls with MSVC. Maybe even BCC, if its tools make it possible. For me this is only important to make GNU-make equal in feature with non-GNU so we can drop the latter. But still, making these the default is going totally the wrong way IMO. We should provide it for those who need it but not for Harbour core please. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
