Hi Przemek,
Maybe some other tool. libtool is only wrapper to native platform
tools and it does not support whole functionality.
Please check ar parameters and maybe releated programas.
libtool --config
should show the configuration. Look for used archiver.
Not supported in OSX :/
---
silver:harbour vszakats$ libtool --config
libtool: unknown option character `-' in: --config
Usage: libtool -static [-] file [...] [-filelist listfile[,dirname]] [-
arch_only arch] [-sacLT]
Usage: libtool -dynamic [-] file [...] [-filelist listfile[,dirname]]
[-arch_only arch] [-o output] [-install_name name] [-
compatibility_version #] [-current_version #] [-seg1addr 0x#] [-
segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table
<filename>] [-seg_addr_table_filename <file_system_path>] [-all_load]
[-noall_load]
---
[ -config also doesn't work. ]
There is something called otool, but it doesn't seem
to be the answer either.
Propably for multiarch libraries different program is used
and it should be able to extract object files.
In fact we should add second build pass for shared library
to GNU make which will use different compile time switches
and will create shared library directly from object files.
But it's hard to touch sth what is used for such many platforms.
I like the .sh way of creating dynamic libs, since it's
much faster than doing two passes, it's also good IMO to
have a common set of build flags to avoid any unnecessary
complexities.
True however, that GNU-make should also properly support
non-Linux/Unix environment (notably Windows BCC/MSVC),
where such a second pass might be unavoidable (but I'm not
100% sure if this is really the case), but for sure for
those platforms where .sh is not available.
Anyhow, the dynamic lib creation would truly be better if
integrated into the GNU-make process. And this is definitely
something to do _after_ 1.0.0.
I just hope we can tweak something to make a unibin OSX
release possible. Maybe the best temp solution should be
to drop shared libs on this platform, since it doesn't
truly effect the usefulness of Harbour, overall.
Each platform uses it's own scripts. AFAIR for SunOS in
config/sunos/gcc.cf was strictly necessary to remove the
space after CC_OUT = -o
Okay, I don't mean to make wide changes here,
but if you have any idea how to protect the
ending space in Darwin gcc.cf, it'd be great. I had no
success with CC_OUT = "-o " and CC_OUT = '-o '.
CC_OUT = -o$(subst x,x, )
Great, thanks.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
