Hi!
David Coe wrote:
> Other than calling the c: drive, these seem identical to those obtained
> here. Trying the #include_next directive then gives:
>
> $ echo '#include_next <stdlib.h>' | gcc -E -I import -
> # 1 "<stdin>"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "<stdin>"
> # 1 "import/stdlib.h" 1
>
> # 1 "g:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h"
> [...]
>
> which worryingly shows no change in calling order.
Of course not. #include_next is normally used inside a .h file, and only
to load the next file in the search order that has the same short name.
Otherwise, it behaves exactly as #include. In particular, it does not
change the search order.
But it does pick up the right files in the right order on your system.
> Anyway, using #include_next <stdlib.h> gives the following symptoms of a
> missing system header whereas #include "/mingw/include/stdlib.h" builds
> to completion.
Then g:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h
and /mingw/include/stdlib.h might be different files. Ever run a diff on
the two of them?
> g++ -O2 -Wall -g -I../ffmpeg/include/ffmpeg -I../import
> -I/usr/local/include -I.
> -DQT3_SUPPORT -DHAVE_LIB_MAD -DHAVE_LIB_A52 -DHAVE_LIB_AO
> -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -I../../qt-3/include/Qt
> -I../../qt-3/include/QtCore -I
> ../../qt-3/include/QtGui -I../../qt-3/include/Qt3Support
> -I../../qt-3/include -
> c -o ../import/stdlib.o ../import/stdlib.cpp
> ../import/stdlib.cpp: In function `int vasprintf(char**, const char*,
> char*)':
> ../import/stdlib.cpp:4: error: `malloc' was not declared in this scope
> ../import/stdlib.cpp:4: warning: unused variable 'malloc'
> make: *** [../import/stdlib.o] Error 1
> make: Leaving directory `/usr/local/dvbcut/src'
A stdlib.h that doesn't declare malloc isn't very std. But this might as
well be a C++ scope/namespace issue.
Speaking of it, I have no idea why stdlib.cpp is a C++ source file (I
didn't write it). It contains only plain C code, and should not be
compiled with g++. import/stdlib.h should guard its declarations with an
"extern "C" {}" block, on the other hand, and #include <stdlib.h>
instead of "stdlib.h".
>>I suppose your MinGW installation is not as "standard" as you think.
>
>
> Clearly this is true (as you guys' Windows build environments work), but
> what ails mine remains a mystery! It may be grasping at straws but I am
> building with a 32-bit toolchain on a 64-bit host. However, any other
> helpful hints greatfully received :-).
Maybe MinGW just doesn't like to be installed on drive G:.
--
Michael "Tired" Riepe <mich...@mr511.de>
X-Tired: Each morning I get up I die a little
------------------------------------------------------------------------------
_______________________________________________
DVBCUT-user mailing list
DVBCUT-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dvbcut-user
