Hi Przemek,
It cannot pick sources from different dirs and/or
cannot put target into different dirs. I can't remember,
but each time I have to deal with GNU make, I end up
spending days on it without any results.
I think that I do not understand what exactly you want to do.
IMHO it can and i
On Wed, 06 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> It cannot pick sources from different dirs and/or
> cannot put target into different dirs. I can't remember,
> but each time I have to deal with GNU make, I end up
> spending days on it without any results.
I think that I do not understand
On Wed, Aug 6, 2008 at 5:11 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> Okay, I understand. I understand your main development
> platform is Linux, so to rephrase the question a bit,
> does GCC on Linux has such incremental linking feature?
I don't know.
> how snappy is a modify/compile/link
Hi Lorenzo,
On Wed, Aug 6, 2008 at 4:14 PM, Szakáts Viktor [EMAIL PROTECTED]> wrote:
Do you know if MinGW's linker has support for
incremental linking in recent versions?
Sorry I don't know.
For me msys/mingw, like Mac's xcode, are simply "compatibility tools".
I update the the hg reposito
On Wed, Aug 6, 2008 at 4:14 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> Do you know if MinGW's linker has support for
> incremental linking in recent versions?
Sorry I don't know.
For me msys/mingw, like Mac's xcode, are simply "compatibility tools".
I update the the hg repositories and type
Hi Lorenzo,
Do you know if MinGW's linker has support for
incremental linking in recent versions?
One of the things that put me off using MinGW,
is that linking my .exe (which is 20megs using -gc3)
takes so much more time than with BCC32, which
has the incremental linking feature (albeit
it some
On Wed, Aug 6, 2008 at 2:59 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> Okay, I've checked all my m* dirs and there turned out
> to be some leftovers from the past, so I'm currently
> testing the cleaned environment. There are a few
> strangenesses still, like missing make.exe from mingw,
> ev
Hi Przemek,
Windows in general) was and still - after 10 years -
is such a PITA to work with.
I haven't made any real Windows builds for very long time
but AFAIR it was very easy to setup MinGW and MSYS environment.
You have to sets of GNU tools one designed for MSYS and 2-nd
for Windows com
On Wed, 06 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> I know have two pre-build manual instructions for
> MinGW, and it doesn't help to make the process
> automatic or easy to port or replicate.
> Currently I have to rename msys sh.exe to sh-.exe
> to make MinGW builds possible using the Window
Hi Przemek,
Okay, I see now. What I still don't see is how to
assemble a properly usable MinGW environment without
manual hacks.
I know have two pre-build manual instructions for
MinGW, and it doesn't help to make the process
automatic or easy to port or replicate.
Currently I have to rename ms
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Finally I simply copied over sed.exe from msys to mingw dir,
> and this way it worked without the error. Thanks for the tip.
> [ I wonder however how these tools are meant to be used properly,
> if even a 'sed' cannot work consistently along
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> I've checked and they are added, so the problem
> seems to be that the public zlib, pcre interface
> is not marked as HB_EXPORT (or export by any
> other means).
It should not be a problem. The HB_EXPORT attribute is necessary
only for exte
Hi Przemek,
I've changed mainstd to hbmainstd, and it worked altough the
result looked quite strange :), after that I've rebuilt it
with -shared, and it gave a 'compress2' missing entry.
Which pbly indicates that hbzlib is missing from harbour.dll
in non-GNU make.
It should be added just like
Hi Lorenzo,
I've changed C: to /c/ everywhere except the PATH.
[ but it didn't fix the sed problem. ]
The sed you should use is the one inside msys which is in c:\msys
\1.0\bin.
Mixing msys and non-msys tools is the main source of problems.
msys is a posix env and it means the c:\bin\harbou
On Tue, Aug 5, 2008 at 5:53 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> I've changed C: to /c/ everywhere except the PATH.
> [ but it didn't fix the sed problem. ]
The sed you should use is the one inside msys which is in c:\msys\1.0\bin.
Mixing msys and non-msys tools is the main source of
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> >MAJOR=`sed -e '!HB_VER_MAJOR!!d' -e 's![^0-9]*\([^ ]*\).*!\1!g'
> >"${FVER}"`
> >MINOR=`sed -e '!HB_VER_MINOR!!d' -e 's![^0-9]*\([^ ]*\).*!\1!g'
> >"${FVER}"`
> >REVIS=`sed -e '!HB_VER_REVISION! !d' -e 's![^0-9]*\([^ ]*\).*!\1!g
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Well, there is no "WinMain" at all in harbour-vc.dlls, but
> there is one '?DllEntryPoint@@' in C++, and a
> '[EMAIL PROTECTED]' in C.
As workaround I can add WinMain() or main() dynamically in hb* scripts
and add -gui switch for window
Hi Przemek,
MAJOR=`sed -e '/HB_VER_MAJOR/!d' -e 's/[^0-9]*\([^ ]*\).*/\1/
g'<"${FVER}"`
MINOR=`sed -e '/HB_VER_MINOR/!d' -e 's/[^0-9]*\([^ ]*\).*/\1/
g'<"${FVER}"`
REVIS=`sed -e '/HB_VER_REVISION/ !d' -e 's/[^0-9]*\([^ ]*\).*/\1/
g'<"${FVER}"`
This didn't change the results.
MAJOR
Hi Przemek,
So, to give a short list of Windows .dll problems:
- 'sed' command line error.
This is probably caused by the C: prefix in your paths.
Probably if you use /c/ instead then this message will
disappear. I'll try to located it and add some workarounds.
Thanks, I'll update my envir
On Tue, 05 Aug 2008, Przemyslaw Czerpak wrote:
Hi Viktor,
> > So, to give a short list of Windows .dll problems:
> > - 'sed' command line error.
> This is probably caused by the C: prefix in your paths.
> Probably if you use /c/ instead then this message will
> disappear. I'll try to located it an
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> So, to give a short list of Windows .dll problems:
> - 'sed' command line error.
This is probably caused by the C: prefix in your paths.
Probably if you use /c/ instead then this message will
disappear. I'll try to located it and add some w
Hi Przemek and all,
So, to give a short list of Windows .dll problems:
- 'sed' command line error.
- harbour*.dll naming in non-GNU make system.
- harbour.dll install location doesn't match in GNU ('lib') and non-
GNU ('bin') builds.
- harbour.dll content doesn't match in GNU and non-GNU (missi
Try it now. I've just committed workaround.
Seeing your other message I think that it can be caused by C:
drive specification. AFAIR MinGW support alternative /c/
*nix like path convention. Anyhow now it should work.
Okay. I did. There were only these sed command line problems:
--
./bin/postinst
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> I've manually built harbour.dll using the above method,
Try it now. I've just committed workaround.
Seeing your other message I think that it can be caused by C:
drive specification. AFAIR MinGW support alternative /c/
*nix like path conven
Hi Przemek,
This is my starter batch file, if it helps:
--
@echo off
set PATH=C:\devl\MinGW-412\bin\;C:\devl\msys\1.0\bin\;%PATH%
set HB_INC_APOLLO=C:/devl/Apollo/include
set HB_INC_CURL=C:/devl/curl/include
set HB_INC_FIREBIRD=C:/devl/Firebird/include
set HB_INC_FREEIMAGE=C:/devl/FreeImage/Dis
hb-mkslib.sh harbour.dll libhbvm.a libhbrtl.a libhbcommon.a
but it's not necessary. ./make_gnu.sh install will be enough.
I've manually built harbour.dll using the above method,
and I can now confirm that MSVS2005cpp, MSVS2005,
MSVS2008cpp, MSVS2008 work with the MinGW built harbour.dll.
I'v
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> ./bin/postinst.sh
> C:\work\harbour\harbour\bin\postinst.sh: ../bin/hb-func.sh: No such
> file or directory
> make: *** [install] Error 1
There is problem with dirname in you msys environment.
Looks that for ./bin/postinst.sh:
dirname
Hi Przemek,
Surely, it would be better. I believe all compilers should
be able to produce a compatible .dll.
Okay, I've now built Harbour using make_gnu.sh, I don't know
how a shared lib looks like, but there are surely not any
harbour*.dll created.
My fault, I forgot that harbour shared lib
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Surely, it would be better. I believe all compilers should
> be able to produce a compatible .dll.
> Okay, I've now built Harbour using make_gnu.sh, I don't know
> how a shared lib looks like, but there are surely not any
> harbour*.dll crea
Maybe this works in the MinGW shell environment,
but I tried it only once so far (in non-Harbour context),
so I'm highly unfamiliar with it.
Just click on MSys icon and then make:
cd
./make_gnu.sh
Okay it's now running. Pretty smoothly actually.
[ Only make_gnu.sh clean took quite a whi
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Maybe this works in the MinGW shell environment,
> but I tried it only once so far (in non-Harbour context),
> so I'm highly unfamiliar with it.
Just click on MSys icon and then make:
cd
./make_gnu.sh
> Even if hb-mkslib worked
> i
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Okay, my only problem is how to create harbour.dll
> with MinGW (or the GNU-make system in general)?
Just simply run make_gnu.sh from MSYS. It will create
harbour shared library automatically.
> [ BTW, maybe hbrtl.dll (or something else) w
Hi Lorenzo,
[ I suspect it's not supported. ]
I can't explain the details.
What I know is that if I want a dynamic lib I only need to pass the
object file to hb-mkslib and the result is a dynamic lib.
And if I want to get small exe I only need to change from -static to
-shared and the apps
On Tue, Aug 5, 2008 at 12:53 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> I have no plans to touch the GNU-make system
> in any ways this close to the release, I just
> simply have no idea how to do that currently,
> that's why I was asking.
>
> [ I suspect it's not supported. ]
I can't explai
Hi Lorenzo,
I have no plans to touch the GNU-make system
in any ways this close to the release, I just
simply have no idea how to do that currently,
that's why I was asking.
[ I suspect it's not supported. ]
Brgds,
Viktor
On 2008.08.05., at 10:35, Lorenzo Fiorini wrote:
On Tue, Aug 5, 2008 at
Hbrtl01_00_00.dll for versioning
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor
Sent: Tuesday, August 05, 2008 9:39 AM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] harbour.dll revisited
Hi Przemek,
Okay, my only
On Tue, Aug 5, 2008 at 9:38 AM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> Okay, my only problem is how to create harbour.dll
> with MinGW (or the GNU-make system in general)?
Simply to remind that GNU-make system is the same for
Linux/Windows/Mac OS X and many other OSes so every change should
Hi Przemek,
Okay, my only problem is how to create harbour.dll
with MinGW (or the GNU-make system in general)?
[ BTW, maybe hbrtl.dll (or something else) would be
a better name for harbour.dll, as it's current name
implies that it's a dependency of harbour.exe. ]
Brgds,
Viktor
On 2008.08.05.,
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Do we want to make any steps towards a standardized harbour.dll?
> I'd suggest to rename harbour-vc.dll to harbour.dll as a step now.
> This means we consider the MSVC compiler as the standard and
> required tool to build our standard harbou
Hi all,
Do we want to make any steps towards a standardized harbour.dll?
I'd suggest to rename harbour-vc.dll to harbour.dll as a step now.
This means we consider the MSVC compiler as the standard and
required tool to build our standard harbour.dll.
In the meantime BCC created harbour.dll will
40 matches
Mail list logo
