Hi Lorenzo, On Sun, Feb 22, 2009 at 6:10 PM, Lorenzo Fiorini <[email protected]> wrote:
> On Sun, Feb 22, 2009 at 10:42 AM, Viktor Szakáts <[email protected]> > wrote: > Just found this mail. I don't wants to force you to use shared libs simply under Linux > static linking is deprecated. > Look in https://fedoraproject.org/wiki/Packaging/Guidelines I agree we should adhere to the local OS standards (and if there is no such thing, expectations and common sense) for all install kits (shared for Linux, static for Windows, IMO static for Darwin). However we should also make sure to create usable build for the rest of the situations, too. This means when we building Harbour for non-package purposes, and we're not installing it into system dirs (analog to local or embedded usage scenerio), it should still work "out of the box". Now, building with shared libs in these cases currently can cause broken tools on some systems. So probably default make system should always generate dynamic libs, but should create static executables, and postinst should overwrite the static executables with dynamic ones when this is needed (installing to system location, creating Linux package). so if we want to see harbour included someday in "main" distributions, > we have to provide both shared and static or only shared but never > only static and the shared support has to work out of the box. Yes. > F.e. I've added these switches to hb* scripts: > > -gd # link with hbgd library (GD interface) > -curl # link with hbcurl library (cURL interface) > -odbc # link with hbodbc library (ODBC interface) > -pgsql # link with hbpgsql library (PostgeSQL interface) > -mysql # link with hbmysql library (MySQL interface) > -xhgtk # link with xHGtk library (GTK+ interface) > > and I build the shared libs at the end of the make_gnu.sh using: > ... > HB_SHARED_LIB="libhbpgsql" > > if [ -f "$HB_SHARED_LIB.a" ]; then > echo "Creating shared lib $HB_SHARED_LIB..." > if [ "$HB_ARCHITECTURE" = "linux" ]; then > hb-mkslib $HB_SHARED_LIB "$HB_SHARED_LIB.a" -lpq > fi > if [ "$HB_ARCHITECTURE" = "win" ]; then > hb-mkslib "$HB_BIN_INSTALL/$HB_SHARED_LIB.dll" > "$HB_SHARED_LIB.a" -L$HB_DIR_PGSQL/lib -lpq > $HB_BIN_INSTALL/harbour.dll $HB_DIR_PGSQL/bin/libpq.dll > fi > if [ "$HB_ARCHITECTURE" = "darwin" ]; then > hb-mkslib $HB_SHARED_LIB "$HB_SHARED_LIB.a" > -L$HB_DIR_PGSQL/lib -lpq > fi > fi > ... > > there are surely better way to do it, but IMHO build system has to > provide the support for a full shared env. > > How this can be done using hbmk2? As far as generating shared contrib libs go, we should try to find a way to solve these locally inside the respective contrib dirs, which means possibly as part of local 'Makefile's. We probably need a new target named 'dyn.cf', and dynlib logic generalized and synced for all platforms, accessible by GNU make process. Just ideas for the future (next major release probably), ideas are welcome how to solve this cleanly. [ we need implib logic to be implemented similarly for Windows compilers, currently it's centralized in postinst.bat, which is not ideal. ] Regarding hbmk2, the idea is to use .hbp files, which store these libnames and paths, and you just pass your xhgtk.hbp file in your cmdline. See some (untested) examples in utils/hbmk2/examples Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
