[MacPorts] #38379: New port "databases/sysbench"

MacPorts noreply at macports.org
Wed Mar 13 15:23:44 PDT 2013


#38379: New port "databases/sysbench"
----------------------------------+--------------------------------
  Reporter:  alexander.janssen@…  |      Owner:  macports-tickets@…
      Type:  submission           |     Status:  new
  Priority:  Normal               |  Milestone:
 Component:  ports                |    Version:  2.1.3
Resolution:                       |   Keywords:  haspatch
      Port:  sysbench             |
----------------------------------+--------------------------------

Comment (by alexander.janssen@…):

 Replying to [comment:7 egall@…]:
 > ok, after building, I have the following comments:

 Thanks for your review comments!

 > - Since you're patching Makefile.am and configure.ac anyways, you might
 as well silence the glibtoolize warnings while you're at it, i.e.:
 > {{{
 > glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac
 > }}}
 >  and
 > {{{
 > glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
 > }}}

 Actually, I tried the `AC_CONFIG_MACRO_DIR([m4])` part. It resulted in a
 situation that it expected a directory named "m4" - if it doesn't exists,
 it bails out.
 If I create the m4 directory, it still bails out for reasons I didn't
 fully understand yet. Probably because it's empty? I checked on the
 Internet and the general opinion was "this is autoconf-foo, just don't do
 it and you're fine."
 Adding `-I m4` to ACLOCAL_AMFLAGS in Makefile.am results in a situation
 that `libtool` is throwing a lot of error-messages. Log from manual
 configure:

 {{{
 /bin/sh ../libtool --tag=CC   --mode=link gcc -D_THREAD_SAFE  -g -O2
 -o sysbench sysbench.o sb_timer.o sb_options.o sb_logger.o db_driver.o
 tests/fileio/libsbfileio.a tests/threads/libsbthreads.a
 tests/memory/libsbmemory.a tests/cpu/libsbcpu.a tests/oltp/libsboltp.a
 tests/mutex/libsbmutex.a drivers/mysql/libsbmysql.a
 -L/opt/local/lib/mysql55/mysql -lmysqlclient_r  -lz   -lm
 ../libtool: line 835: X--tag=CC: command not found
 ../libtool: line 868: libtool: ignoring unknown tag : command not found
 ../libtool: line 835: X--mode=link: command not found
 ../libtool: line 1001: *** Warning: inferring the mode of operation is
 deprecated.: command not found
 ../libtool: line 1002: *** Future versions of Libtool will require
 --mode=MODE be specified.: command not found
 ../libtool: line 2228: X-D_THREAD_SAFE: command not found
 ../libtool: line 2228: X-g: command not found
 ../libtool: line 2228: X-O2: command not found
 ../libtool: line 1948: X-L/opt/local/lib/mysql55/mysql: No such file or
 directory
 ../libtool: line 2397: Xsysbench: command not found
 ../libtool: line 2402: X/Users/ajanssen/gnuradio/lib: No such file or
 directory
 ../libtool: line 2409: Xsysbench: command not found
 ../libtool: line 2417: mkdir /.libs: No such file or directory
 }}}

 I wasn't able to debug this one, but the Internet is full of people
 complaining about the same or similar errors - the only working solution I
 found is running the whole autogen.sh, aclocal, autoconf and automake
 yadda-yadda - something autoreconf is supposed to do (I guess). So I
 decided to ignore it completly because it just breaks things. I have the
 feeling that this is a GNU autotools compability issue. I'm not confident
 enough to fully debug this.

 > - The +mysql4 and +mysql5 variants should probably conflict with one
 another

 People might have valid reasons to have several different versions of
 their client-libs installed. mysql4 and mysql5 can live happily together
 without getting in the way of each other. Or what do you mean? That those
 two variants can't be installed side-by-side...? (I assumed that)

 > - mysql4 is old and obsolete anyway (I couldn't get it to build on
 Lion), so you could also just leave out the +mysql4 variant instead

 I only included it for completeness. I think it just should be fixed in
 the mysql4 port, but I don't see a point to fix the client libs just to
 make sysbench work. What do you suggest? Should I remove it and include it
 later when the mysql4 port builds again? (should check if there's already
 a ticket opened for mysql4 not building)

 > - my [https://github.com/cooljeanius/macportsscripts/blob/v0.1.4/port-
 depcheck.sh port-depcheck.sh] script says that `sysbench` doesn't actually
 link against openssl or zlib; do those really need to be added as
 dependencies? Although then again I like to add lots of irrelevant
 dependencies when writing my own ports, so who am I to talk...

 This is actually kinda odd, I noticed it myseld. The mysql5 port links
 itself against openssl by default, mysql55 doesn't. Mysql55 has the
 `+openssl` variant. So I think I'll include the openssl dependency for
 mysql5 only.

 > Also re-looking over the portfile, all instances of the word
 "`sysbench`" can be replaced with the variable `${name}`

 Allright.

 So, I'll try to fix the things I can solve right now; you want me to
 submit a new portfile and delete the old attachment?

-- 
Ticket URL: <https://trac.macports.org/ticket/38379#comment:8>
MacPorts <http://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list