Hi Phil,
>> 1) Use whatever HB_INSTALL_PREFIX we may have at build pass.
>> 2) Reapply this parameter on install? (if that's possible)
>
> probably it can be done using otool.
>
>> 3) Else?
>
> I think that on OS X, one is supposed to produce application bundles
> which include all libraries no
On Sat, Nov 21, 2009 at 9:08 PM, Viktor Szakáts wrote:
> Just did this on SVN, pls make some tests and
> report if there is still something missing.
For me now it's ok.
Now everything works using DYLD_LIBRARY_PATH=/opt/harbour/lib ./demoqt.
best regards,
Lorenzo
___
On Sat, Nov 21, 2009 at 11:53 PM, Phil Krylov wrote:
> On Sat, Nov 21, 2009 at 11:08 PM, Viktor Szakáts wrote:
>> 2) Reapply this parameter on install? (if that's possible)
>
> probably it can be done using otool.
there seems to be a specific tool for this - install_name_tool.
-- Ph.
__
On Sat, Nov 21, 2009 at 11:08 PM, Viktor Szakáts wrote:
> of dylibs. Plus such requirement makes it not possible
> to move around .dylib once it's created (but maybe this
> how it's meant to be done on OS X).
>
> What to do?
>
> 1) Use whatever HB_INSTALL_PREFIX we may have at build pass.
> 2) Rea
> I had fixed this locally by changing
>
> -install_name "harbour$(DYN_EXT)"
>
> to
>
> -install_name "libharbour$(DYN_EXT)"
>
> in DY_RULE (should probably fix also mkdyn).
Just did this on SVN, pls make some tests and
report if there is still something missing.
> Anyhow, this is a hack as
I had fixed this locally by changing
-install_name "harbour$(DYN_EXT)"
to
-install_name "libharbour$(DYN_EXT)"
in DY_RULE (should probably fix also mkdyn).
Anyhow, this is a hack as install_name should (usually) be set to the
full installation path.
--Ph.
_
>> Why whole dir is stripped and why 'lib' prefix is stripped
>> from dylib reference? Maybe because of -L option with the
>> same dir
>
> Could it be this?
>
> config/darwin/gcc.mk
> ...
> DY_RULE = $(DY) $(DFLAGS) -install_name "harbour$(DYN_EXT)"
> -compatibility_version $(HB_VER_MAJOR).$(HB_V
>>> In my local repo I set HB_DLL=no and I use the "old" hb-mkslib logic
>>> that's now commented out in hb-func.sh and it works as expected.
>>>
>>> In the "old way" otool -D /opt/harbour/lib/libharbour.dylib returns
>>> libharbour.dylib in the "svn way" it returns harbour.dylib.
>>
>> Could you
On Sat, Nov 21, 2009 at 7:21 PM, Viktor Szakáts wrote:
> Why whole dir is stripped and why 'lib' prefix is stripped
> from dylib reference? Maybe because of -L option with the
> same dir
Could it be this?
config/darwin/gcc.mk
...
DY_RULE = $(DY) $(DFLAGS) -install_name "harbour$(DYN_EXT)"
-comp
On Sat, Nov 21, 2009 at 8:09 PM, Viktor Szakáts wrote:
>>> Why whole dir is stripped and why 'lib' prefix is stripped
>>> from dylib reference? Maybe because of -L option with the
>>> same dir?
>>
>> The problem seems not in the hbmk2 but how the libharbour.dylib is generated.
>>
>> In my local re
>> Why whole dir is stripped and why 'lib' prefix is stripped
>> from dylib reference? Maybe because of -L option with the
>> same dir?
>
> The problem seems not in the hbmk2 but how the libharbour.dylib is generated.
>
> In my local repo I set HB_DLL=no and I use the "old" hb-mkslib logic
> that
On Sat, Nov 21, 2009 at 7:21 PM, Viktor Szakáts wrote:
> Why whole dir is stripped and why 'lib' prefix is stripped
> from dylib reference? Maybe because of -L option with the
> same dir?
The problem seems not in the hbmk2 but how the libharbour.dylib is generated.
In my local repo I set HB_DLL
>> This difference is due to the fact that Harbour is installed
>> to system location on your system and not on mine. hbmk2 will
>> adapt and use full dirspec to link against dylib. Anyhow the
>> problem is present in both cases apparently.
>
> In my local repo I remove all that HB_SYSLOC logic in
On Sat, Nov 21, 2009 at 6:39 PM, Viktor Szakáts wrote:
> This difference is due to the fact that Harbour is installed
> to system location on your system and not on mine. hbmk2 will
> adapt and use full dirspec to link against dylib. Anyhow the
> problem is present in both cases apparently.
In m
Hi Lorenzo,
>> Rather hbmk2 should be modified if possible to load
>> it without requiring such links.
>
> hbmk2 -traceonly demoqt
> gcc demoqt.o hbmk_gvsy4s.o -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork
> -lsupc++ -lhbcplr -lhbdebug -lharbour
> /Library/Frameworks/QtCore.framework/QtCore
> /Libr
On Sat, Nov 21, 2009 at 12:16 PM, Viktor Szakáts wrote:
> Rather hbmk2 should be modified if possible to load
> it without requiring such links.
hbmk2 -traceonly demoqt
hbmk2: Processing environment options: -compiler=gcc
hbmk2: Processing local make script: hbmk.hbm
hbmk2: Processing configurat
Rather hbmk2 should be modified if possible to load
it without requiring such links.
Any ideas how to do this?
This is current link command when using -shared mode:
---
hbmk2: Linker command:
/Developer/usr/bin/gcc hbide.o hbmk_KNOaaX.o
To get ./demoqt working after hbmk2 demoqt I have to do ln -s
libharbour.dylib harbour.dylib.
Any comment?
best regards,
Lorenzo
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman
18 matches
Mail list logo
