[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk-devel
Subject:    Re: [Netatalk-devel] UAMs: why the 'M'?
From:       Philip Edelbrock <phil () netroedge ! com>
Date:       2003-01-30 18:41:21
[Download RAW message or body]


Sebastian Rittau wrote:

>
>Netatalk uses libtool for module generation. libtool uses a sane
>approach and is widely used and well tested. I don't think that we
>should support systems that are broken enough that libtool support is
>impossible for them.
>  
>
Something is broken with libtool when Netatalk is built on OS-X.  To get 
the UAMs to build, I needed to hand edit the libtool script to avoid 
violations in the flags passed to gcc.  Libs also had the wrong suffixes 
(I saw ".so" when they should have been ".dylib" for OS-X).  Perhaps it 
is an old libtool?

>I actually consider modularization (and also run-time modules) to ease
>the maintainance of Netatalk on the code level as well as the
>administrative level.
>
I think the code could be organized in a basic way to keep it well 
organized and easier to maintain without the odd API for external shared 
object files.  The current system has additional code overhead which 
requires more maintenance (like keeping libtool up to date? :').  The 
current system also depends on an undefined system of dynamic objects 
calling functions in the linking app, which may not be universally 
reliable.  It's clever, but seemingly not vary portable the way it is now.

>What are your specific problems with the current approach? What doesn't
>work? What are the error messages?
>
Some problems I had include: names of shared lib files were ".so" or 
".yes" instead of ".dylib".  And, libtool throws the '-install_name' 
flag w/ the '-bundle' which isn't allowed (stopping the build with an 
error).  For details, read the thread from a few weeks ago entitled 
'Anyone compiled for OSX?'

Sorry, I'm actually trying to drive at a solution and not just complain. 
;')  I suggest we simplify the UAM system and simply link it in.  I was 
wondering if there was a serious need for the current way the auth stuff 
is modularized, but it seems that there is not (any longer, anyway).  In 
the short term, it may be helpful to have the libtool in the Netatalk 
distro updated, if that is indeed part of the problem?


Phil



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Netatalk-devel mailing list
Netatalk-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-devel
[prev in list] [next in list] [prev in thread] [next in thread]