On Mon, 13 May 2013, Martin Storsjö wrote:
If this is explicitly disabled for win32/mingw, it should also
be disabled for cygwin, for consistency and for the same reasons
as for win32/mingw.
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index b67a8bf..c84050c 100755
--- a/configure
+++ b/configure
@@ -3084,6 +3084,7 @@ case $target_os in
SHFLAGS='-shared -Wl,--out-implib,$(SUBDIR)lib$(FULLNAME).dll.a'
objformat="win32"
enable dos_paths
+ disable pic
;;
*-dos|freedos|opendos)
network_extralibs="-lsocket"
--
1.7.9.4
This turned out to actually break the cygwin builds:
http://fate.libav.org/x86_64-cygwin-gcc-4.9
And now, looking closer at these things, it seems that pieces of inline
assembly do rely on PIC being defined (while nothing for x86 uses
CONFIG_PIC).
So, what do people suggest - revert the parts where we disable pic for
mingw and cygwin? For win32 (with msvc, without inline assembly), it
shouldn't matter either way. For ICL, which should be able to support some
kind of inline assembly with a bit of tweaking, I don't know...
Or should we change those pieces of code to check both for PIC and __PIC__
(and/or __pic__)? That feels kinda ugly on the other hand.
I don't mind reverting all of the disabling of pic, but then we'd need
another way of disabling it for msvc/arm (short of requiring the caller to
add --disable-pic).
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel