On Tuesday 22 December 2009 17:42:03 Bruno Friedmann wrote:
> Thanks for fixing it.
>
> Kern did you thing it's better that I make my effort to next 3.1 versions
> and check with the actual trunk ?

I cannot answer that question because I don't really know what you are doing.  
3.1.7 is quite stable, and it will be released soon, but it is not currently 
released so it should only be used in production for those who are ready to 
assume the risks of something being broken.

Yes, I am aware of the various xxx_config programs, thanks.  Unfortunately, 
they are not manditory on Linux systems.

Regards,

Kern

>
> It seems that mysql has also a nice config
> this the extract for my opensuse 11.2
>
> mysql_config
> Usage: /usr/bin/mysql_config [OPTIONS]
> Options:
>         --cflags         [-I/usr/include/mysql  -fomit-frame-pointer
> -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -DPIC -fPIC -DUNDEF_HAVE_INITGROUPS
> -fno-strict-aliasing   -DUNIV_LINUX] --include       
> [-I/usr/include/mysql]
>         --libs           [-L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl
> -lm -L/usr/lib -L/usr/lib64 -lssl -lcrypto] --libs_r        
> [-L/usr/lib/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread
> -L/usr/lib -L/usr/lib64 -lssl -lcrypto]
>         --plugindir      [/usr/lib/mysql/plugin]
>         --socket         [/var/run/mysql/mysql.sock]
>         --port           [0]
>         --version        [5.1.36]
>         --libmysqld-libs [-L/usr/lib/mysql -lmysqld -ldl -lz -lpthread
> -lcrypt -lnsl -lm -lpthread -lwrap -lrt -L/usr/lib -L/usr/lib64 -lssl
> -lcrypto]
>
>
> here for a old 10.3 (mysql 5.0x version)
> mysql_config
> Usage: /usr/bin/mysql_config [OPTIONS]
> Options:
>         --cflags         [-I/usr/include/mysql -march=i586 -mtune=i686
> -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -g -DPIC -fPIC
> -DUNDEF_HAVE_INITGROUPS -fno-strict-aliasing]
>         --include        [-I/usr/include/mysql]
>         --libs           [-L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl
> -lm -L/usr/lib -lssl -lcrypto] --libs_r         [-L/usr/lib/mysql
> -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread -L/usr/lib -lssl
> -lcrypto] --socket         [/var/lib/mysql/mysql.sock]
>         --port           [3306]
>         --version        [5.0.45]
>         --libmysqld-libs [-L/usr/lib/mysql -lmysqld -lz -lpthread -lcrypt
> -lnsl -lm -lpthread -lwrap -lrt -L/usr/lib -lssl -lcrypto]
>
> On 12/21/2009 10:54 AM, Kern Sibbald wrote:
> > On Monday 21 December 2009 09:39:43 Eric Bollengier wrote:
> >> Le dimanche 20 décembre 2009 21:34:51, Kern Sibbald a écrit :
> >>> On Sunday 20 December 2009 20:59:05 Eric Bollengier wrote:
> >>>> Le dimanche 20 décembre 2009 19:26:43, Eric Bollengier a écrit :
> >>>>> Postgres gives an API call to determine if the client is thread-safe
> >>>>> or not, perhaps MySQL do the same (i will check).
> >>>>
> >>>> MySQL API has mysql_thread_safe() (found on 3.1/4.0 manual)
> >>>> PostgreSQL has PQisthreadsafe() (but only for >= 8.2)
> >>>> SQLite3 has sqlite3_threadsafe()
> >>>>
> >>>> Do you think that possible to test the result of this function in the
> >>>> ./configure ? (I would say yes, and i can look tomorrow)
> >>>
> >>> Yes, it is possible, but a bit ugly to do.
> >>
> >> The ./configure output contains many hacks like that.
> >>
> >> PostgreSQL has a nice pg_config prog that should help to avoid ugly
> >> testing to find options like includedir, libdir, binary path, etc...
> >>
> >> $ pg_config --includedir
> >> /usr/include
> >>
> >> $ pg_config --libdir
> >> /usr/lib
> >>
> >> I think that we can have the same kind of prog to get config.out and
> >> configure option available for support.
> >
> > Yes, we are using such config programs more and more in ./configure, and
> > this is one we can probably add.  The problem is that not all users have
> > them installed -- all these little xxx_config programs should be a
> > required part of the base system.
> >
> >>>> We can use the old way as workaround for postgresql 8.0, and 8.1
> >>>
> >>> What I suggest is I change the current code in configure so that it
> >>>  complains but it does not disable batch insert.  Then we add new code
> >>> that uses the API calls and if batch insert is turned on when we try to
> >>> open a connection and thread safe is not enabled, we M_ABORT Bacula.
> >>
> >> I will add the code in this way.
> >>
> >>> For old postgres versions, we warn the user in the documentation.
> >
> > As far as I can tell, the problem I was seeing was localized to our
> > current development version.  I have now fixed it.  Until we find a
> > better method, I am planning to leave the current ./configure code in
> > place, but I think we should go ahead with implementing the API calls
> > either in the current development version or in the next one as time
> > permits.
> >
> > Kern
> >
> > -------------------------------------------------------------------------
> >----- This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support A
> > streamlined, 14 day to market process makes app distribution fast and
> > easy Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > _______________________________________________
> > Bacula-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bacula-devel



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to