Przemyslaw,
I was answering to Viktor since he named OS/2 and asking him why he did change
linux (or more in general unix compitible) scripts instead of creating new ones
for macosx.
I was not saying you're against adding new command for macosx or anything like
that.
This just for clarificati
On Fri, 21 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> in OS/2 there is an envvar, LIBPATH=, which always contains '.' and is used by
> OS/2 to find needed DLLs; so every program looks at the dirctory it was
> started from when looking for .DLLs.
> I don't think this is available on MacOSX.
I
Szakáts Viktor wrote:
>
> Windows, OS/2 and DOS doesn't need an (extended) installer,
> and this makes them very flexible to use. IMO, if there is
> any chance to replicate that (and I believe there is),
> we shouldn't cut the way to allow this on as much platforms
Viktor,
in OS/2 there is an en
Hello Viktor,
On 2008/11/20 Szakáts Viktor <[EMAIL PROTECTED]> wrote:
>>
>> Well, then I'd guess that the rpath should be embedded into the
>> harbour executable and the executables generated by it. Adding
>> "--rpath=" (or maybe "-Wl,rpath,> path>", not tested) to the gcc command line should do
All my questions were aimed towards a binary distribution.
F.e. our current 1.0.1 for OSX package on sf.net download
page.
[ I know these can be controlled when building from source
and running 'make install', this is exactly how it's working
here locally on OS X, Linux and Windows. ]
For the re
Hi Viktor,
On 2008/11/19 Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> All my questions were aimed towards a binary distribution.
> F.e. our current 1.0.1 for OSX package on sf.net download
> page.
>
> [ I know these can be controlled when building from source
> and running 'make install', this is
Hi Maurilio,
I think that compilers come with package installer (instead of being a
packaged app, like, for example, a browser) and the installer puts
libraries
where they have to go, see for example neooffice which has such an
'extended'
installer.
For me both are just applications. IMO
Hi Lost,
- How to install two Harbour versions in parallel with installation
technique?
You can use HB_INSTALL_PREFIX to specify a local path.
All my questions were aimed towards a binary distribution.
F.e. our current 1.0.1 for OSX package on sf.net download
page.
[ I know these can be co
Hi, guys.
On 2008/11/19 Szakáts Viktor <[EMAIL PROTECTED]> wrote
> - How to install two Harbour versions in parallel with installation technique?
You can use HB_INSTALL_PREFIX to specify a local path.
>
> - How to use Harbour without admin/sudo rights with installation technique?
> (suppose I'
I think in this discussion you are mixing an end-user app, like google-earth,
and a compiler, like harbour.
I think that compilers come with package installer (instead of being a
packaged app, like, for example, a browser) and the installer puts libraries
where they have to go, see for example neo
Here are the installetion steps for Oracle Client in OSX taken from
http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/intel_macsoft.html
:
1. See the installation guide for all system requirements.
2. Download the appropriate Instant Client packages for your platfor
Hi Przemek,
I do not see any way that you may change you preferences.
Yes, and you seemingly cannot accept that these
preferences can have valid grounds or they they
may even exist, at the same time you simply ignore
them without adding arguments.
Questions/facts you've ignored:
- How to inst
On Tue, Nov 18, 2008 at 7:38 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> Hi Przemek,
>
>> 1. Why I cannot execute this simple scrpit in MacOSX port:
>>
>>#!/usr/bin/hbrun
>>proc main()
>> alert( "Hello World!!!" )
>>return
>>
>> I have big internet shop ap
On Tue, 18 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
>>> Anyhow, it turns out - miracle - that there is about
>>> 50MB worth of _static libs inside_, plus the executable.
>> There is no even single static library or binary in GoogleEarthLinux.bin.
>> All libraries and executable files are linked
Just to give a quick idea of the problem and one solution,
I've just downloaded Google Earth for Linux, and after I've
found out that the file GoogleEarthLinux.bin is a really a
script which needs to be started from terminal (guess
whether your mom / dad / gf / wife / sister could find this
out).
This should work regardless of our static vs. dynlib issue.
So it's off topic.
No. It's pefectly related to your arguments.
Such scirpts needs strict hbrun localization.
Then, everyone who needs this functionality should
install Harbour. That's it.
The same is with shared library.
Fine, bu
On Tue, 18 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
> Just to give a quick idea of the problem and one solution,
> I've just downloaded Google Earth for Linux, and after I've
> found out that the file GoogleEarthLinux.bin is a really a
> script which needs to be started from terminal (guess
> w
On Tue, 18 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
>> #!/usr/bin/hbrun
>> proc main()
>>alert( "Hello World!!!" )
>> return
>> I have big internet shop application which with hundreds
>> CGI harbour scripts and it does not work with MacOSX.
> This
I do not agree. You both are thinking only about your current needs.
I want to be able to write Harbour applications as scripts or
binaries and distribute them in system friendly packages like
RPM or DEB. It means that I need Harbour installed in known
...
which will keep some basic rules between
Hi Przemek,
1. Why I cannot execute this simple scrpit in MacOSX port:
#!/usr/bin/hbrun
proc main()
alert( "Hello World!!!" )
return
I have big internet shop application which with hundreds
CGI harbour scripts and it does not work with MacOSX.
T
On Tue, Nov 18, 2008 at 3:18 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> I do not agree. You both are thinking only about your current needs.
> I want to be able to write Harbour applications as scripts or
> binaries and distribute them in system friendly packages like
> RPM or DEB. It mea
Hi Przemek,
Il 18/11/2008 15.18, Przemyslaw Czerpak ha scritto:
On Tue, 18 Nov 2008, Szak�ts Viktor wrote:
I have big internet shop application which with hundreds
CGI harbour scripts and it does not work with MacOSX.
For curiosity I would like to see a your "real life" job in a
On Tue, 18 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
> Macports is one (Linux-like) 3rd party solution. [ I try to
> not use it, as it adds up a difficult to replicate component
> to an otherwise clean system. You need to do sudo/admin, which
> I also try to avoid. ]
Before you will change sth
Macports is one (Linux-like) 3rd party solution. [ I try to
not use it, as it adds up a difficult to replicate component
to an otherwise clean system. You need to do sudo/admin, which
I also try to avoid. ]
Do you know nay other way to have gd, openssl and other developers
libs?
I haven't ex
On Tue, Nov 18, 2008 at 12:03 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> Macports is one (Linux-like) 3rd party solution. [ I try to
> not use it, as it adds up a difficult to replicate component
> to an otherwise clean system. You need to do sudo/admin, which
> I also try to avoid. ]
Do you
Hi Lorenzo,
The problem is that in Mac OSX there are more arch combinations than
developers :)
For example yesterday I wanted to test the new gtk beta and I followed
the 1,2,3 steps suggested at http://www.gtk-osx.org, It installed like
a charm in perfect OSX style but they simply forgot to men
On Tue, Nov 18, 2008 at 2:53 AM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> I see only one problem. So far no one invest time to create
> native MacOSX packages which will put Harbour binaries and
> libraries in the OS friendly directories using OS packaging
> system.
The problem is that in
Hi Przemek,
I see only one problem. So far no one invest time to create
native MacOSX packages which will put Harbour binaries and
libraries in the OS friendly directories using OS packaging
system.
All of the above what you said is only results of such missing
functionality which you mixed wit
On Tue, 18 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
> Because in OS X such experience is simply unprecedented
> in the user world, and because it gives _no_ advantage
> _at all_ on this platform, which is 99.99% aimed for desktop
> users. At the same time it makes the binaries simply unusable,
Hi Przemek,
just copy the missing file from /lib to next to the executable,
and always use -static when using hbmk script.
Why??? In all *nixes dynamic linking is a base and static
is sth seldom used for some specific reasons.
Because in OS X such experience is simply unprecedented
in the us
On Mon, 17 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
> just copy the missing file from /lib to next to the executable,
> and always use -static when using hbmk script.
Why??? In all *nixes dynamic linking is a base and static
is sth seldom used for some specific reasons.
If there is sth wrong
To the OSX problem (which doesn't appeared on my mailbox,
only the web archive):
just copy the missing file from /lib to next to the executable,
and always use -static when using hbmk script.
BTW, I think we should rename the dynamic builds of our
supplied binaries to hbrun-dyn and hbtest-dyn, s
32 matches
Mail list logo
