Hello Christian, Let me answer your question about dictionary initialization. This may be of interest for other people also, so I will upload this to roottalk. There are few different situations in this context. Let me categorize them as follows. 1) ROOT, dictionary as shared library > G__cpp_setupG__Base1 > G__cpp_setupG__Base2 > G__cpp_setupG__Base3 > G__cpp_setupG__Clib > G__cpp_setupG__Cont > G__cpp_setupG__Meta > G__cpp_setupG__Net > G__cpp_setupG__Unix > >and nowhere G__cpp_setup! Your question is understood. ROOT has different dictionary initialization system. Rootcint creates a class and a static instance of it in the dictionary. What it does is to setup a pointer to dictionary initialization routine in Cint core. This is done by calling G__add_setup_func() in the dictionary. The information is stored in to G__setup_func_struct that is defined in init.c. When Cint main function G__main() is called, G__call_setup_funcs() is called. There, all of the dictionary initialization routines are called. So, dictionary initialization does not rely on the file name. 2) Pure CINT, dictionary as shared library Pure CINT uses different method. ROOT's method is very nice, however, it can only be used for C++ dictionary, not a C dictionary. For C, I needed to provide different system anyway. And for pure CINT, I decided to go with this one scheme only. makecint/cint -c-1|2 generates dictionary with G__cpp_setup or G__cpp_setup<libname>. This can be switched by cint command line option. When shared library is loaded, G__shl_load() searches for both version of initialization routine. There are a few platform dependent limitation here, so some platform, both version works fine, in others only one side works. (if I remember correctly) In theory, G__cpp_setup should work because in shared library can duplicate same function names in different files. But, this has lead some confusion to some users in the past. Please see below. Generally speaking, for UNIX, 'makecint -dl' creates G__cpp_setup<x> for Win32 'makecint -dl' creates G__cpp_setup You may ask that I can live with G__cpp_setup for UNIX too. But some people does static linking of this library to CINT which causes name conflict. For Win32, I am not allowing it by not let a user see the <libname>.lib file. 3) Pure CINT, dictionary as static library or shared library but statically linked with CINT. Here is the reason why we need G__cpp_setup<x>. Some compiler or environment can not allow dynamic linking of shared library. Or in some cases, a user wants to statically link multiple dictionaries with CINT core. In such case, you can not have more than one G__cpp_setup() because of name duplication. You always have to have G__cpp_setup<x> in order to distinguish each dictionary. So in this case, for both UNIX and WIN32, 'makecint -o' creates G__cpp_setup<x>. Is this clear enough? And about autoload tool, It can be worth adding autotool version of build script to CINT package. Could you provide me the first version of it? I do not have enough knowledge to create it from scratch. At this moment, I am still not convinced to switch everything to autotool, but having that option can be interesting. Thank you Masaharu Goto >Date: Thu, 03 May 2001 17:38:17 +0200 >From: Christian Holm Christensen <cholm@hehi03.nbi.dk> >To: MXJ02154@nifty.ne.jp >Cc: cholm@hehi03.nbi.dk, Richard.Kreckel@Uni-Mainz.DE >Subject: RE:CINT source code questions > >Hi Masa, > > >On Tue, 1 May 2001 18:50:55 +0900 >Masaharu Goto <MXJ02154@nifty.ne.jp> wrote >concerning ": RE:CINT source code questions": >> I think I understand your concern. Cint does not take absolute path, but >> the file name only. >> >> $ cint /home/xxx/yyy/libBar.so -> G__cpp_setuplibBar() >> ------ ------ >> >> As I explained already, cint also looks for G__cpp_setup(). > >Yes I got that, but that's not the issue. The idea is, which at least >works for ROOT, that you create _two_ files FooCint.cxx and >BarCint.cxx and link both FooCint.o and BarCint.o into the same >library, so the G__cpp_setup would be doubly defined, so it cannot be >define in the two files FooCint.o and BarCint.o. Also, the final >resulting library may have an enterily different name, like libBaz.so >e.g., nothing to do with Foo and Bar! > >This means that you'll have symbols > > G__cpp_setupFooCint > G__cpp_setupBarCint > >and so on, in the library libBaz.so. So how does CINT find those? It >cannot do it from the name (libBaz.so) only, since that may have >nothing to do with it. > >This is not just an academic question. In ROOT, several rootcint >generated files are compiled and linked into the same library. For >example, in $ROOTSYS/lib/libCore.so, you'll find > > G__cpp_setupG__Base1 > G__cpp_setupG__Base2 > G__cpp_setupG__Base3 > G__cpp_setupG__Clib > G__cpp_setupG__Cont > G__cpp_setupG__Meta > G__cpp_setupG__Net > G__cpp_setupG__Unix > >and nowhere G__cpp_setup! > >I hope this illustrates a bit better what I can't figure out. Maybe >it's some special ROOT feature, but I don't think so from looking at >the code. > >> >Oh, that's easy. Have in a Makefile.am the lines like >> >> This is interesting. Let me think for a while... > >It's also possible to include extra sources dependent on what >configure finds on the system. For example, if you want to >conditionally compile the libreadline library, dependent on wether >it's on the system or not, you can do something like > > AC_CHECK_LIB(readline, readline) > AM_CONDITIONAL(HAVE_READLINE, test "x$ac_cv_lib_readline_readline" = "xyes" ) > >in configure.in, and in Makefile.am > > if HAVE_READLINE > SUBDIRS = readline ... > else > SUBDIRS = ... > endif > >And similar for example libdl. Also, if you need some extra source >files dependent on the platform, you can do something like > > AC_CANONICAL_SYSTEM > case $host in > *-*-linux*) arch=linux ;; > *-*-sunos4.*) arch=sun ;; > *-*-solaris*) arch=solaris ;; > *-*-hpux*) arch=hpux ;; > *-*-osf*) arch=osf ;; > *-*-aix*) arch=aix ;; > *-*-irix*) arch=irix ;; > *) AC_MSG_ERROR([Unknown platform $host]) ;; > esac > AM_CONDITIONAL(CONFIG_HOST_LINUX, test "x$arch" = "xlinux") > AM_CONDITIONAL(CONFIG_HOST_SUN, test "x$arch" = "xsun") > AM_CONDITIONAL(CONFIG_HOST_SOLARIS, test "x$arch" = "xsolaris") > AM_CONDITIONAL(CONFIG_HOST_HPUX, test "x$arch" = "xhpux") > AM_CONDITIONAL(CONFIG_HOST_OSF, test "x$arch" = "xosf") > AM_CONDITIONAL(CONFIG_HOST_AIX, test "x$arch" = "xaix") > AM_CONDITIONAL(CONFIG_HOST_IRIX, test "x$arch" = "xirix") > >and > > if CONFIG_HOST_LINUX > OSSOURCES = ... > endif > if CONFIG_HOST_SOLARIS > OSSOURCES = ... > endif > ... > >As you see, it's quite possible to define various variables and so on, >in a very generic fashion using, GNU Autotools. > >Yours, > >Christian ----------------------------------------------------------- >Holm Christensen Phone: (+45) 35 35 96 91 > Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 > DK-2200 Copenhagen N Web: www.nbi.dk/~cholm > Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:44 MET