svn commit: samba r3737 - in branches/SAMBA_4_0/source: auth
build/pidl build/smb_build lib lib/dcom
lib/dcom/common lib/registry lib/registry/common
lib/tdb libcli/auth librpc/rpc ntvfs ntvfs/cifs ntvfs/ipc
ntvfs/nbench ntvfs/posix ntvfs/print ntvfs/simple
ntvfs/unixuid rpc_server rpc_server/dcom rpc_server/remote smbd
jelmer at samba.org
Wed Nov 17 11:24:40 GMT 2004
Hi Tridge, Metze,
Most of the changes I have been making to the build system are due to
realization that there really shouldn't be much difference between
subsystems, modules and libraries at build level. They all three:
- Are collections of functions spread over multiple source/object files
- Have dependencies on other subsystems/modules/libraries
- Have zero or more init functions that need to be called when
the module/subsystem/library in question is used.
Binaries in Samba consist of one or more source/object files and use one or
more modules/subsystems/libraries (let's call them "buildparts").
buildparts can be built in three different ways:
- as collections of object files. Dependency checking and making sure
an object isn't included more then once is done at build level. IMHO
this method should only be used on systems that don't have support
- as static libraries (.a files). Dependency checking is done at build
level. Basically just a bunch of .o files put together in an
- as shared libraries (.so files):
The linker takes care of dependency resolving (very useful!). These shared
libraries can then be either directly linked to the executable or loaded
dynamically. Because the module can be linked against the buildparts it uses
the linker can take care of resolving unknown symbols by loading the
necessary libraries (in that case no need for lazy resolving). We
could also have a "has_function("functionname")" function that uses dlsym(NULL,
"functionname") to check whether "functionname" is available in the
current program. This way we won't need to register subsystems.
The problem with the init functions that have to be called is
currently solved by generating a list of init functions that is called
by a binary at start-up. This should be kept in use for older
compilers. Newer compilers support the "constructor" attribute that
allows you to mark functions that have to be run before main() is
started. The constructor functions will be called when the library
they're in is loaded, so they'll work for both static libraries,
single object files and dynamically loaded libraries (whether they're
loaded at start-time or by dlopen() doesn't matter). Using the
constructor attribute will allow us to not have to fiddle with
recompiling .o files when the list of buildparts for a binary changes
and it will allow using the samba libraries by external developers
without the need for them to call a whole bunch of init functions.
I hope the story above is understable :-) If I haven't explained
something clearly, let me know.
I'm currently working on (optionally) supporting the __attribute__ ((constructor)).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20041117/5be7931d/attachment.bin
More information about the samba-technical