#2017: osgf compilation errro
-----------------------+----------------------------------------------------
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: libc | Platform: Linux
Cpu: x86-64 |
-----------------------+----------------------------------------------------
Hi, recently I discovered problem when compiling `ogsflib`.
{{{
In file included from /usr/include/x86_64-linux-gnu/sys/stat.h:106:0,
from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/config.h:311,
from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/gis.h:28,
from GK2.c:21:
/usr/include/x86_64-linux-gnu/bits/stat.h:91:21: error: field ‘st_atim’
has incomplete type
/usr/include/x86_64-linux-gnu/bits/stat.h:92:21: error: field ‘st_mtim’
has incomplete type
/usr/include/x86_64-linux-gnu/bits/stat.h:93:21: error: field ‘st_ctim’
has incomplete type
In file included from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/config.h:311:0,
from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/gis.h:28,
from GK2.c:21:
/usr/include/x86_64-linux-gnu/sys/stat.h:366:31: error: array type has
incomplete element type
/usr/include/x86_64-linux-gnu/sys/stat.h:373:54: error: array type has
incomplete element type
}}}
Replying to [ticket:2017 martinl]:
> Hi, recently I discovered problem when compiling `ogsflib`.
>
{{{
In file included from /usr/include/x86_64-linux-gnu/sys/stat.h:106:0,
from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/config.h:311,
from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/gis.h:28,
from GK2.c:21:
/usr/include/x86_64-linux-gnu/bits/stat.h:91:21: error: field ‘st_atim’
has incomplete type
/usr/include/x86_64-linux-gnu/bits/stat.h:92:21: error: field ‘st_mtim’
has incomplete type
/usr/include/x86_64-linux-gnu/bits/stat.h:93:21: error: field ‘st_ctim’
has incomplete type
In file included from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/config.h:311:0,
from /home/martin/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/include/grass/gis.h:28,
from GK2.c:21:
/usr/include/x86_64-linux-gnu/sys/stat.h:366:31: error: array type has
incomplete element type
/usr/include/x86_64-linux-gnu/sys/stat.h:373:54: error: array type has
incomplete element type
}}}
>
> Debian GNU/Linux Unstable
> Any idea what could be wrong?
Yes, my recent addition of `#include <sys/stat.h>` to config.h.in. Try to
add `#include <sys/stat.h>` or `#include <unistd.h>` or both as in
Weird that it works on different Linux systems, FreeBSD, Solaris, IBM AIX,
but not on Debian GNU/Linux Unstable. If it works on Debian Stable, I
would recommend to hack your local copy.
Replying to [comment:6 martinl]:
> Replying to [comment:5 mlennert]:
> > Martin,
> >
> > Can you confirm this issue, or can we close the bug ?
>
> I can still confirm this issue. I have reinstalled `libc6-dev` package
(`libc6-dev:amd64 (2.17-92)`), but it didn't help.
Here with gcc (Debian 4.7.3-4) 4.7.3 and the same libc6-dev package on
Debian testing, and your CFLAGS I still cannot reproduce. Maybe you could
try with gcc 4.8 as Hamish did ? Anything in your local copy of the source
?
what version of libavutil does that provide?
(look in /usr/include/libavutil/avutil.h for
LIBAVUTIL_VERSION_MAJOR,MINOR,MICRO)
supposedly newer versions of Debian have switched to more stable versions
of these libraries which could put an end to this game of cat and mouse,
but I'm tempted to drop the in-program MPEG creation in favour of creating
a series of frames and outsourcing the encoding entirely to 3rd party
software.
anyway IIRC that code isn't used by anything in trunk right now, so no
benefit of using --with-ffmpeg when building GRASS 7 (currently).
Replying to [comment:10 hamish]:
> what version of libavutil does that provide?
> (look in /usr/include/libavutil/avutil.h for
LIBAVUTIL_VERSION_MAJOR,MINOR,MICRO)
Replying to [comment:8 martinl]:
> OK, the reason is that `/usr/include/libavutil` already contains
`time.h` header file
It appears that they '''really''' don't want anyone else to use their
library.
Just one more reason to abandon FFMPEG support. If we didn't have enough
of those already.
My I tactfully disagree? If one needs libffmpeg functions, by all means
use them. Just lets not get carried away with compiler include directives.
I've reproduced the particular problem as originally reported by martini
on Fedora fc19 and fc20, where it is readily fixed:
1. remove /usr/include/libavutil/ from --with-ffmpeg-includes paths
2. lib/ogsf/gsd_img_mpeg.c line 33 should read #include <libavutil/mathematics.h>
rather than #include <mathematics.h>
That should be all that is necessary, for now. As a general point,
however, one
might opine that *all* libffmpeg #includes should be written relative to
the first
--with-ffmpeg-includes="/usr/include"
directory, or on Fedora
--with-ffmpeg-includes="/usr/include/ffmpeg"
as shown above, though as a practical matter the "configure" script fails
if it
can't find at least some of the ffmpeg subdirectories and I wouldn't
insist we fix such a thing that isn't otherwise broken.
Think of the "top-level only" paradigm as being a method for maintaining
separate
namespaces for different development libraries. If in our Makefiles we
"-I<everything under the sun>", then <everything under the sun> must have
a unique file name, rather than just a unique relative path. Given enough
libraries with
enough separate headers, sooner or later we're going to have name
collisions. We
happened to hit one with libffmpeg. But if such is our philosophy, if not
here it was going to happen another time, somewhere else.
if we're not using it in trunk, and AFAIK we aren't since tcl/tk nviz went
away, my vote is to just drop the dependency & outsource the problem to
mencoder et al.
On the other hand, if you'd like me to fix it I can continue with the
information provided in comment:11.
Replying to [comment:15 hamish]:
Well, I'm not a GRASS dev, but fwiw while the #include
<libavutil/mathematics.h> fix to gsd_img_mpeg.c enabled a successful build
back in January, more recently I've run into problems with ctypes
generation / python wrapping when FFMPEG was enabled, e.g. at svn revision
59324:
...and stops (with 4% cpu usage in python process). I haven't traced the
source, but this doesn't occur when I remove --with-ffmpeg and friends
from my configuration script, and grass7_svn then successfully builds. I'm
not reporting this as a bug, only as an fyi that there may exist ffmpeg
issues beyond the include paths, should you choose to pursue them.
So, current state is that GRASS has to be compiled without `ffmpeg`
(`avutil`):
{{{
--with-ffmpeg=no
}}}
This probably applies to all GRASS branches and most of the platforms.
''Removing status from the ticket title. Please keep discussion about
ticket status in ticket comments.''