Opened 11 years ago
Closed 10 years ago
#2017 closed defect (fixed)
ogsf compilation error
Reported by: | martinl | Owned by: | |
---|---|---|---|
Priority: | blocker | Milestone: | 7.0.0 |
Component: | Compiling | Version: | svn-trunk |
Keywords: | libc, ogsf, libavutil, ffmpeg | Cc: | |
CPU: | x86-64 | Platform: | Linux |
Description
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
gcc --version gcc (Debian 4.7.3-5) 4.7.3
Package: libc6-dev Versions: 2.17-7
CFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \ CXXFLAGS="-g -Wall" \ ./configure --prefix=/home/martin/smetiste/g7 \ --with-postgres --with-postgres-includes=/usr/include/postgresql \ --with-gdal=/usr/local/bin/gdal-config \ --with-proj --with-cxx --enable-largefile --with-sqlite \ --with-motif --with-glw --with-nls --with-readline \ --with-freetype --with-freetype-includes=/usr/include/freetype2 \ --with-odbc --with-python=/usr/bin/python-config --with-wxwidgets \ --with-ffmpeg \ --with-ffmpeg-includes="/usr/include/libavcodec /usr/include/libavformat/ /usr/include/libswscale /usr/include/libavutil/" \ --with-geos=/usr/local/bin/geos-config --with-pthread \ --with-mysql --with-mysql-includes=/usr/include/mysql --with-cairo \ --with-liblas --with-readline-libs=/lib/x86_64-linux-gnu --with-openmp --with-opencl \ --with-netcdf --with-x --x-includes=/usr/include --x-libraries=/usr/lib/x86_64-linux-gnu
Any idea what could be wrong?
Change History (26)
comment:1 by , 11 years ago
Summary: | osgf compilation errro → osgf compilation error |
---|
comment:2 by , 11 years ago
comment:4 by , 11 years ago
Hi,
using today's debian/unstable (gcc 4.8.1-6, libc6-dev 2.17-7) and today's grass trunk, all builds ok for me, no errors. Martin, perhaps try again?
Hamish
follow-up: 6 comment:5 by , 11 years ago
Martin,
Can you confirm this issue, or can we close the bug ?
Moritz
follow-up: 7 comment:6 by , 11 years ago
Replying to 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.
comment:7 by , 11 years ago
Replying to martinl:
Replying to 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 ?
Moritz
follow-ups: 9 12 comment:8 by , 11 years ago
OK, the reason is that /usr/include/libavutil
already contains time.h
header file (1). I am using
--with-ffmpeg-includes="/usr/include/libavcodec /usr/include/libavformat/ /usr/include/libswscale /usr/include/libavutil"
without /usr/include/libavutil
I get
gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or directory #include <mathematics.h>
comment:9 by , 11 years ago
Replying to martinl:
OK, the reason is that
/usr/include/libavutil
already containstime.h
header file (1). I am using
apt-file search /usr/include/libavutil/time.h libavutil-dev: /usr/include/libavutil/time.h ... Package: libavutil-dev Source: libav Version: 6:0.8.7-1
follow-up: 11 comment:10 by , 11 years ago
Keywords: | osgf libavutil added |
---|
martinl wrote:
gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or directory
lib/ogsf/gsd_img_mpeg.c
/* FFMPEG stuff */ #ifdef HAVE_FFMPEG #include <avformat.h> #include <avio.h> #if LIBAVUTIL_VERSION_MAJOR < 51 #include <avutil.h> #else /* libavutil 51.22.1's avutil.h doesn't include libavutil/mathematics.h */ #include <mathematics.h> #endif
Package: libavutil-dev Source: libav Version: 6:0.8.7-1
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).
Hamish
comment:11 by , 11 years ago
Replying to hamish:
what version of libavutil does that provide? (look in /usr/include/libavutil/avutil.h for LIBAVUTIL_VERSION_MAJOR,MINOR,MICRO)
version.h:#define LIBAVUTIL_VERSION_MAJOR 52 version.h:#define LIBAVUTIL_VERSION_MINOR 18 version.h:#define LIBAVUTIL_VERSION_MICRO 100
comment:12 by , 11 years ago
Replying to martinl:
OK, the reason is that
/usr/include/libavutil
already containstime.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.
follow-up: 21 comment:13 by , 11 years ago
Summary: | osgf compilation error → osgf compilation error (fixed?) |
---|
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:
- remove /usr/include/libavutil/ from --with-ffmpeg-includes paths
- 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.
comment:14 by , 11 years ago
Priority: | blocker → critical |
---|
follow-up: 16 comment:15 by , 11 years ago
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.
regards, Hamish
comment:16 by , 11 years ago
Replying to 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:
python -t -3 -m py_compile /home/leaver/project/Grass/Fedora/grass7_svn/dist.x86_64-unknown-linux-gnu/etc/python/grass/lib/vedit.py
Status: Processing description list.
Error: /usr/include/GL/gl.h:90: Syntax error at '\n'
Error: /usr/include/GL/gl.h:93: Syntax error at '\n'
Status: Processing description list.
...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.
comment:17 by , 11 years ago
Keywords: | ffmpeg added |
---|---|
Summary: | osgf compilation error (fixed?) → osgf compilation error |
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.
comment:18 by , 11 years ago
Keywords: | ogsf added; osgf removed |
---|---|
Summary: | osgf compilation error → ogsf compilation error |
follow-up: 20 comment:19 by , 10 years ago
See also GRASS-dev G7: OGSF compilation error on Ubuntu 14.04 for some more error messages.
According to the ticket, this applies to Debian and Ubuntu (14.04). I don't understand if this applies to Fedora.
comment:20 by , 10 years ago
Replying to wenzeslaus:
According to the ticket, this applies to Debian and Ubuntu (14.04). I don't understand if this applies to Fedora.
No issues on Fedora.
comment:21 by , 10 years ago
FWIW, I tested edleaver's suggestion on Ubuntu 14.04:
Replying to edleaver: ...
- remove /usr/include/libavutil/ from --with-ffmpeg-includes paths
- 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.
... unfortunately no success:
grass70_release/lib/ogsf$ make gcc -g -O2 -fPIC -I/home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include -I/home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include -I/usr/include/gdal -I/usr/include -DPACKAGE=\""grasslibs"\" -I/usr/include/postgresql -I/usr/include/libavcodec -I/usr/include/libavformat -I/usr/include/libswscale -I/usr/include/libavutil -I/home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include -I/home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/GK2.o -c GK2.c In file included from /usr/include/x86_64-linux-gnu/sys/stat.h:105:0, from /home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/defs/gis.h:64, from /home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:636, from GK2.c:21: /usr/include/x86_64-linux-gnu/bits/stat.h:91:21: error: field ‘st_atim’ has incomplete type struct timespec st_atim; /* Time of last access. */ ^ /usr/include/x86_64-linux-gnu/bits/stat.h:92:21: error: field ‘st_mtim’ has incomplete type struct timespec st_mtim; /* Time of last modification. */ ^ /usr/include/x86_64-linux-gnu/bits/stat.h:93:21: error: field ‘st_ctim’ has incomplete type struct timespec st_ctim; /* Time of last status change. */ ^ In file included from /home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/defs/gis.h:64:0, from /home/alba/source_code/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:636, from GK2.c:21: /usr/include/x86_64-linux-gnu/sys/stat.h:365:31: error: array type has incomplete element type const struct timespec __times[2], ^ /usr/include/x86_64-linux-gnu/sys/stat.h:372:54: error: array type has incomplete element type extern int futimens (int __fd, const struct timespec __times[2]) __THROW; ^ make: *** [OBJ.x86_64-unknown-linux-gnu/GK2.o] Error 1
follow-ups: 23 24 comment:22 by , 10 years ago
A reminder, ffmpeg is not used with trunk, only for creating animations directly in tcl/tk NVIZ in grass 6.
suggest to remove it from libogsf and configure.in in trunk.
Hamish
comment:23 by , 10 years ago
Priority: | critical → blocker |
---|
Replying to hamish:
A reminder, ffmpeg is not used with trunk, only for creating animations directly in tcl/tk NVIZ in grass 6.
suggest to remove it from libogsf and configure.in in trunk.
Sounds reasonable. Marked as blocker for the 7.0 release.
comment:24 by , 10 years ago
Replying to hamish:
A reminder, ffmpeg is not used with trunk, only for creating animations directly in tcl/tk NVIZ in grass 6.
suggest to remove it from libogsf and configure.in in trunk.
I removed ffmpeg in r61305. I've used autoconf2.13
. Compilation after make distclean
works. wxNVIZ and m.nviz.image
(and g.gui.animation
) work.
I updated REQUIREMENTS.html but I don't know what is appropriate update for the following files:
I don't understand why, if I leave the parameters
--with-ffmpeg=no --with-ffmpeg-includes="/usr/include/libavcodec /usr/include/libavformat /usr/include/libswscale /usr/include/libavutil"
in my ./configure
call, no error is reported.
comment:25 by , 10 years ago
r61305 backported to 7.0 in r61678 no further changes done, so comment:24 still applies.
comment:26 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Since everything compiles fine, closing this ticket. Open a new one in case of further troubles.
Replying to martinl:
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 into config.h.in:311.
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.