Please email any libSieve porting problems to me directly.
No problem. The one problem that I had with building libSieve was
similar in nature to that being discussed here; I should have sent
you a description and proposed patches by the time you read this.
occurs when gcc is called on Mac OS X with the -dynamiclib flag; for
Interesting.
I'll say; I have no idea why it only happens when building dynamic
libraries (though I haven't checked for this problem when building
bundles; see below).
example the successful build (after making the above patches), also
contained this output:
<snip>
/usr/bin/gcc-4.0 -g -O2 -I/opt/local/include/glib-2.0 -I/opt/local/
lib/glib-2.0/include -I/opt/local/include -I/opt/local/include/
gmime-2.0 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/
include -I/opt/local/include -W -Wall -Wpointer-arith -Wstrict-
prototypes -o .libs/dbmail-util maintenance.o -L/opt/local/
lib ./.libs/libdbmail.dylib /opt/local/lib/libgmime-2.0.dylib /opt/
local/lib/libgmodule-2.0.dylib /opt/local/lib/libgthread-2.0.dylib -
lz /opt/local/lib/libgobject-2.0.dylib /opt/local/lib/
libglib-2.0.dylib /opt/local/lib/libintl.dylib -lc /opt/local/lib/
libiconv.dylib
/usr/bin/ld: warning multiple definitions of symbol _quiet
maintenance.o definition of _quiet in section (__DATA,__data)
./.libs/libdbmail.dylib(libdbmail_la-dbmail-user.o) definition of
_quiet
/usr/bin/ld: warning multiple definitions of symbol _verbose
maintenance.o definition of _verbose in section (__DATA,__data)
./.libs/libdbmail.dylib(libdbmail_la-dbmail-user.o) definition of
_verbose
/usr/bin/ld: warning multiple definitions of symbol _yes_to_all
maintenance.o definition of _yes_to_all in section (__DATA,__data)
./.libs/libdbmail.dylib(libdbmail_la-dbmail-user.o) definition of
_yes_to_all
/usr/bin/ld: warning multiple definitions of symbol _no_to_all
maintenance.o definition of _no_to_all in section (__DATA,__data)
./.libs/libdbmail.dylib(libdbmail_la-dbmail-user.o) definition of
_no_to_all
/usr/bin/ld: warning multiple definitions of symbol _reallyquiet
maintenance.o definition of _reallyquiet in section (__DATA,__data)
./.libs/libdbmail.dylib(libdbmail_la-dbmail-user.o) definition of
_reallyquiet
creating dbmail-util
</snip>
Do you get the same set of errors repeated for export.c and
sievecmd.c?
I get them for sievecmd.c, but, oddly, not for export.c.
Since I'm here, I'll also mention one unrelated problem that I
noticed after the successful build: libdbmail was built with the
extension ".dylib", as appropriate for Mac OS X, but libauth_sql and
libsqlite were built with the extension ".so"; I imagine that this
should be fixed.
This might actually be correct. The system links libdbmail, but we're
using Glib to open libauth_foo and libsort_bar. If the applications
work,
then whatever libtool has chosen to do is probably correct.
I looked this up, and it seems that it should be okay. From the Fink
wiki page "Metapkg:dyld and the Darwin Linker" (http://
wiki.finkproject.org/index.php/Metapkg:dyld_and_the_Darwin_Linker):
"Shared libraries on Mac OS X are rather different than most other
unixes. Mac OS X (or, more specifically, its implementation of the
Mach-O binary format) differentiates between shared libraries, i.e.,
common code shared between multiple applications, and loadable
modules, i.e., code that is programmatically loaded at runtime by an
application. On most UNIXen, you can treat a plugin as a library to
link against, or, at runtime, dynamically load a shared library. On
Mac OS X there is a clear delineation between the two (MH_DYLIB for
"shared libraries" and MH_BUNDLE for "plugins"), and (with
exceptions) you can't treat one as the other."
(This is backed up at least from a few terse sentences in http://
developer.apple.com/documentation/Porting/Conceptual/PortingUnix/
compiling/chapter_4_section_9.html, and probably more so in places I
couldn't find.)
According to the Mac OS X ABI Mach-O File Format Reference (http://
developer.apple.com/documentation/DeveloperTools/Conceptual/
MachORuntime/Reference/reference.html):
" * The MH_BUNDLE file type is the type typically used by code that
you load at runtime (typically called bundles or plug-ins). By
convention, the file name extension for this format is .bundle."
However, the Fink wiki page above goes on to say:
"Note that the GNU libtool form of bundle ("plugin") creation will
actually use the extension ".so" instead of ".bundle". The Mac OS X
linker enforces no naming conventions for bundles, and Apple's
guidelines have little to say on the issue, so most ported unix apps
use the GNU libtool convention of ".so", which is common for other
UNIX-like operating systems."
So I guess that there shouldn't be a problem, otherwise the Fink guys
would have said so.
Thank you for helping port to Mac OS X! Will you be maintaining public
packages once everything is building reliably?
I certainly will once they're accepted (I don't have commit rights
yet :-( )
Thank you once again for your help.
Kind regards,
Maun Suang
--
Boey Maun Suang (Boey is my surname)
Mobile: +61 403 855 677
Email: [EMAIL PROTECTED]
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
