Hi Przemek,
#!/bin/bash
export HB_ARCHITECTURE=darwin
export HB_COMPILER=gcc
Both should be detected automatically by make_{gnu,tgz}.sh
Try to remove it. We should know if autodetection works correctly.
Yes, I can confirm autodetection does work.
I'll remove these, they are here from the past.
export C_USR="-arch i386 -arch ppc"
export L_USR="-arch i386 -arch ppc"
I've never tried to create dual platform libraries and I have no idea
if it works. If possible make tests only with natvie platform without
any -arch switches. Then we can try to create multiplatform binaries.
Without the extra switches, it now works perfectly.
(except the 'sed' problem)
#if [ -z "$HB_GT_LIB" ]; then export HB_GT_LIB=gttrm; fi
It's also default. Please remove.
Done.
#if [ -z "$HB_BIN_INSTALL" ]; then export HB_BIN_INSTALL=$PREFIX/
bin; fi
#if [ -z "$HB_LIB_INSTALL" ]; then export HB_LIB_INSTALL=$PREFIX/
lib/harbour; fi
#if [ -z "$HB_INC_INSTALL" ]; then export HB_INC_INSTALL=$PREFIX/
include/harbour; fi
If you do not have PREFIX envvar then location is not the best one.
Here I also rather sugest to remove this. Default locations for
make_tgz.sh
is /usr/local
$PREFIX was commented :(
I'll retry a unibin with this fix.
(It didn't make a difference in .dylib / hbextern problem)
libtool: for architecture: ppc file: ctset.o has no symbols
libtool: for architecture: ppc file: video.o has no symbols
All this files are empty so the warning messages are perfectly
correct.
Yes, indeed.
In file included from ../../hbsqlit3.c:45:
../../sqlite3/sqlite3.c: In function â__full_fsyncâ_t:
../../sqlite3/sqlite3.c:19843: warning: unused parameter
â__dataOnlyâ_t
In file included from ../../hbsqlit3.c:45:
../../sqlite3/sqlite3.c: In function â__full_fsyncâ_t:
../../sqlite3/sqlite3.c:19843: warning: unused parameter
â__dataOnlyâ_t
Just pacify it.
Done.
ar: /var/folders/zE/zEKVnguu2RW3OE+BYw4Bx++++TI/-Tmp-/
harbour.bin.vszakats.76256/usr/local/lib/harbour/libhbextern.a is a
fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: /var/folders/zE/zEKVnguu2RW3OE+BYw4Bx++++TI/-Tmp-/
harbour.bin.vszakats.76256/usr/local/lib/harbour/libhbextern.a:
Inappropriate file type or format
And this may be the reason why shared library is not created.
But I have no idea why hbextern library is different then all others.
It's created in standard build process. Maybe stdout log can say sth
more. Or even better mixed output:
./make_tgz.sh &> mktgz.log
I've tried it, this is what I got:
--
Making libharbour.1.0.0.dylib...
ar: /var/...-Tmp-/harbour.bin.vszakats.24669/usr/local/lib/harbour/
libhbextern.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: /var/...-Tmp-/harbour.bin.vszakats.24669/usr/local/lib/harbour/
libhbextern.a: Inappropriate file type or format
--
So it seems hbextern doesn't "like" unibin, and this causes
the remaining chain of problems.
ranlib: archive library: /var/folders/zE/zEKVnguu2RW3OE+BYw4Bx+++
+TI/-
Tmp-//harbour.bin.vszakats.76256/usr/local/lib/harbour/libhbfm.a will
be fat and ar(1) will not be able to operate on it
This I'll change. hbfm is build in different way then other libraries
It's created with ar and Darwin builds uses libtool.
Thanks. I can confirm it works.
I can confirm that make_tgz.sh now would generate a .tar.gz, so the
sed problem is no more. [ I liked the .inst.sh method though, since
you didn't have to remember any tar switches, but it's fine. ]
Can you remove BASH now? Also the "-o " solution is a bit error
prone in darwin/gcc.cf, could you take a look at it? Notice that
the official GCC -o switch format is using a space, so this might
come as problem on other platforms, too.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
