[Trying again, this time it is Sourceforge that rejects mail from my ISP]
Andrew Hartung wrote:
[]
> Odd, I have my ISP's spam filter off. I think I've received mail from
> you before too.
I think this blacklisting business is somewhat random. My ISP uses
several addresses for its mail server, and some of them are blacklisted,
others not. This is not exactly spam filtering, it is more sinister.
Anyway...
[]
> Ok, changed the make file here:
>
> INSTALL = /sw/bin/ginstall -c
> INSTALL_DATA = ${INSTALL} -m 644
> INSTALL_PROGRAM = ${INSTALL}
> LIB_SUFFIX = .a
> SHLIB_SUFFIX = .dylib
> SHLIB_LD = g++ -bundle -flat_namespace -undefined suppress
> SHLIB_FLAGS = -shared
> STRIP_FLAGS = -S
> LIBEXT = .so
> EXEEXT =
> DESTDIR=
>
>
> but if I changed SHLIB_SUFFIX = .dylib to .so it wouldn't make and
> gave me:
> g++ -g -O2 -fPIC -I../unix/../include -I../unix/../src -I. -o dump \
> ../unix/../demos/dump.cpp libmk4.so -lpthread
> /usr/bin/ld: libmk4.so is input for the dynamic link editor, is not
> relocatable by the static link editor again
Yes, this problem is a little subtler: You need to build libmk4.dylib as
a dylib like it wants to originally, with the -dynamiclib flag, not
-bundle. Only the python module Mk4py.so needs to be changed from .dylib
to .so and from -dynamiclib to -bundle. There is also some tcl stuff,
but since it is not needed for the python module, I haven't looked at
it, so I don't know whether it has to be built as .dylib or as .so. Or
maybe you don't want to build it at all, I don't know.
This distinction between shared libraries (*.dylib) and bundles (*.so)
is a Darwin speciality that is unknown to Linux programmers, and the
metakit Makefile doesn't know about it either.
You have to introduce this distinction. On which level of elegance and
generality you want to do this is up to you; you can simply fix the
Makefile "by hand" after it is generated by configure and replace every
ocurrence of "Mk4py$(LIBEXT)" and of "Mk4py$(SHLIB_SUFFIX)" by
"Mk4py.so", and in the linker line for the Mk4py.so target change
$(SHLIB_LD) to
g++ -bundle -flat_namespace -undefined suppress
or you can teach the configure.in script about the existence of bundles
by adding two lines to their Darwin corner:
case $build_os in
Darwin*)
SHLIB_SUFFIX=".dylib"
SHLIB_LD="g++ -dynamiclib -flat_namespace -undefined suppress"
STRIP_FLAGS=-S
;;
Here you could introduce new variables BUNDLE_SUFFIX and BUNDLE_LD and
then modify the Makefile.in file to use these two for the python module.
There are certainly a couple of other possibilities to achieve the same
goal.
[]
> Gourmet built, but gives me the following from the terminal:
[]
> ImportError: No module named metakit
[]
> Why can't it find metakit, because of the way I renamed it?
Because it looks for a "bundle" Mk4py.so and doesn't find it.
--
Martin
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Fink-users mailing list
Fink-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-users
