azynheira / mu0

Automatically exported from code.google.com/p/mu0
0 stars 0 forks source link

Solaris doesn't have struct dirent d_type #32

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Try doing ./configure of mu-0.9.1 on OpenSolaris 2009-06

I'm not a programmer, but looking at another project that has this issue, 
they've used stat(2) instead on solaris, see 
http://patchwork.notmuchmail.org/patch/271/

uname -a output:

SunOS cpmail 5.11 snv_111b i86pc i386 i86pc

Original issue reported on code.google.com by jessedre...@gmail.com on 10 Dec 2010 at 2:17

GoogleCodeExporter commented 8 years ago
./configure ends with:

checking for struct dirent.d_type... no
configure: error: 
   *** We need the d_type member in struct dirent, but it seems
   *** your system does not have it

Original comment by jessedre...@gmail.com on 10 Dec 2010 at 2:17

GoogleCodeExporter commented 8 years ago
we actually already have a similar kind of stat() fallback for some 
file-systems, e.g reiserfs, xfs on linux. however, the fallback currently 
depends on at least having a placeholder 'd_type'-member in struct dirent.

so, this fallback will need some changes to support solaris.

Original comment by digg...@gmail.com on 10 Dec 2010 at 5:54

GoogleCodeExporter commented 8 years ago
Thanks for looking at this issue!

Original comment by jessedre...@gmail.com on 10 Dec 2010 at 10:29

GoogleCodeExporter commented 8 years ago
latest git version has some updates for this; I think this should make it work 
for Solaris, but of course I cannot fully test it. 

You can check it with:
 $ git clone git://gitorious.org/mu/mu-ng.git
 $ cd mu-ng
 $ autoreconf -i 
 $./configure
 $ make distcheck

Please let me know if it works.

Original comment by digg...@gmail.com on 11 Dec 2010 at 12:06

GoogleCodeExporter commented 8 years ago
I've just tried cloning mu-ng.git as above and running autoreconfig -i, here is 
the output:

jesse@cpmail ~/src/mu-ng $ autoreconf -i
configure.ac:11: warning: macro `AM_SILENT_RULES' not found in library
configure.ac:26: error: possibly undefined macro: AM_SILENT_RULES
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

I'm sorry I'm not familiar with using autoconf / automake. Do I need to add 
AM_SILENT_RULES as an allowed macro in m4_pattern_allow?

Original comment by jessedre...@gmail.com on 13 Dec 2010 at 2:10

GoogleCodeExporter commented 8 years ago
Ah, it's probably due to your autotools being from the pre-AM_SILENT_RULES-era.

I think simply commenting out the line that says 'AM_SILENT_RULES' in 
configure.ac should get you a step further. Updating autotools should also 
work, but I guess that could be harder.

Original comment by digg...@gmail.com on 13 Dec 2010 at 5:10

GoogleCodeExporter commented 8 years ago
I'm sorry, I don't think I'm being much use here! 

I've commented out the AM_SILENT_RULES line in configure.ac and tried again but 
it bails thusly:

jesse@cpmail ~/src/mu-ng $ autoreconf -i
configure.ac:20: installing `./missing'
configure.ac:20: installing `./install-sh'
src/Makefile.am:37: Libtool library used but `LIBTOOL' is undefined
src/Makefile.am:37:   The usual way to define `LIBTOOL' is to add 
`AC_PROG_LIBTOOL'
src/Makefile.am:37:   to `configure.ac' and run `aclocal' and `autoconf' again.
src/Makefile.am:37:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
src/Makefile.am:37:   its definition is in aclocal's search path.
src/Makefile.am: installing `./depcomp'
src/tests/Makefile.am:37: Libtool library used but `LIBTOOL' is undefined
src/tests/Makefile.am:37:   The usual way to define `LIBTOOL' is to add 
`AC_PROG_LIBTOOL'
src/tests/Makefile.am:37:   to `configure.ac' and run `aclocal' and `autoconf' 
again.
src/tests/Makefile.am:37:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
src/tests/Makefile.am:37:   its definition is in aclocal's search path.
Makefile.am: installing `./INSTALL'
autoreconf: automake failed with exit status: 1

Original comment by jessedre...@gmail.com on 14 Dec 2010 at 2:12

GoogleCodeExporter commented 8 years ago
I've now added the following line to configure.ac:

AC_PROG_LIBTOOL

autoreconfig -i now runs without complaint. 

However now libgmime is too old (2.2, wants 2.4 or 2.6), I'll pick this up 
again a bit later. 

Original comment by jessedre...@gmail.com on 16 Dec 2010 at 1:44

GoogleCodeExporter commented 8 years ago
OK, installed libgmime 2.4.21 and have got to the point where ./configure 
completes!

mu configuration is complete.
-----------------------------
Xapian version                       : xapian-config - xapian-core 1.2.3
Build unit tests (glib >= 2.16)      : yes
Build 'mug' (requires GTK+)          : gtk2
McCabe's Cyclomatic Complexity tool  : 

Use direntry->d_ino                  : yes
Use direntry->d_type                 : no

type 'make' to build mu, or 'make check' to run the unit tests.
use 'make V=1' to show the detailed output during the build

Original comment by jessedre...@gmail.com on 16 Dec 2010 at 2:20

GoogleCodeExporter commented 8 years ago
excellent! now i'm curious if the build will work...

Original comment by digg...@gmail.com on 16 Dec 2010 at 8:41

GoogleCodeExporter commented 8 years ago
Yeah, there were some issues with compiling. I've posted a message to the list.

Original comment by jessedre...@gmail.com on 16 Dec 2010 at 8:59

GoogleCodeExporter commented 8 years ago
mu 0.9.2 should do the right thing regarding d_type on solaris.

Original comment by digg...@gmail.com on 3 Feb 2011 at 7:56