[Bug 680583] New: routeprot.h has bug related to IP_LOCAL_BINDING
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: routeprot.h has bug related to IP_LOCAL_BINDING
https://bugzilla.redhat.com/show_bug.cgi?id=680583
Summary: routeprot.h has bug related to IP_LOCAL_BINDING
Product: Fedora
Version: 13
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: mingw32-w32api
AssignedTo: rjones(a)redhat.com
ReportedBy: greearb(a)candelatech.com
QAContact: extras-qa(a)fedoraproject.org
CC: rjones(a)redhat.com, kalev(a)smartlink.ee,
fedora-mingw(a)lists.fedoraproject.org
Classification: Fedora
Description of problem:
It seems IP_LOCAL_BINDING is defined after it is used.
Version-Release number of selected component (if applicable):
mingw32-w32api-3.13-5.fc13.noarch
How reproducible:
Always
Steps to Reproduce:
1. Try to compile something that uses routprot.h
2.
3.
Actual results:
In file included from
fea/data_plane/fibconfig/fibconfig_entry_get_iphelper.cc:34:
/usr/i686-pc-mingw32/sys-root/mingw/include/routprot.h:51: error:
'IP_LOCAL_BINDING' does not name a type
scons: ***
[obj/i386-pc-mingw32/fea/data_plane/fibconfig/fibconfig_entry_get_iphelper.o]
Error 1
scons: building terminated because of errors.
Expected results:
Sweet binary goodness.
Additional info:
This seems to fix things:
diff --git a/routprot.h.orig b/routprot.h
index 54fe9ee..2b57df8 100644
--- a/routprot.h.orig
+++ b/routprot.h
@@ -43,6 +43,11 @@ extern "C" {
#define IPX_PROTOCOL_NLSP 0x00020002
/*--- Router Management Reference - Router Management Structures */
#if (_WIN32_WINNT >= 0x0500)
+typedef struct IP_LOCAL_BINDING {
+ DWORD Address;
+ DWORD Mask;
+} IP_LOCAL_BINDING,*PIP_LOCAL_BINDING;
+
typedef struct IP_ADAPTER_BINDING_INFO {
ULONG AddressCount;
DWORD RemoteAddress;
@@ -50,10 +55,7 @@ typedef struct IP_ADAPTER_BINDING_INFO {
ULONGLONG Speed;
IP_LOCAL_BINDING Address[];
} IP_ADAPTER_BINDING_INFO,*PIP_ADAPTER_BINDING_INFO;
-typedef struct IP_LOCAL_BINDING {
- DWORD Address;
- DWORD Mask;
-} IP_LOCAL_BINDING,*PIP_LOCAL_BINDING;
+
typedef struct IPX_ADAPTER_BINDING_INFO {
ULONG AdapterIndex;
UCHAR Network[4];
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
12 years, 10 months
rename mingw-gstreamer-plugins-bad to mingw-gstreamer-plugins-bad-free
by Farkas Levente
hi,
after i find the Erik already checkin the update to newer crt and header
and able to fix the d3d patch now (for me) everything build on rhel-6.
so Erik svn contains spec which is working on both fedora and rhel-6.
i'm just rename mingw-gstreamer-plugins-bad to
mingw-gstreamer-plugins-bad-free as in fedora since the current
mingw-gstreamer-plugins-bad was actually
mingw-gstreamer-plugins-bad-free. i'll create the other (rpmfusion
corresponding) mingw-gstreamer-plugins-bad an
mingw-gstreamer-plugins-ugly build on next week.
and hopefully finally will be abl to start to work on the filesystem
enhancement to cleaner spec file management.
regards.
--
Levente "Si vis pacem para bellum!"
12 years, 10 months
rhel-6 remaining problem
by Farkas Levente
hi,
so what's remain.
i still not be able to rebuild qtlockedfile (which is not needed for me:-)
since it's use
%{_qt4_qmake} -spec win32-g++-cross
which should have to be
%mingw32_qmake_qt4
but they both use %{_qt4_qmake} which is defined in the native qt-x11
pacakge (why the qt rpm macros defined in qt-x11??? imho it's a bug).
but even if i add BuildRequires: qt-x11 i've got:
----------------------------------------
+ /usr/lib/qt4/bin/qmake -spec win32-g++-fedora-cross
Could not find mkspecs for your QMAKESPEC(win32-g++-fedora-cross) after
trying:
/usr/lib/qt4/mkspecs
Error processing project file:
/builddir/build/BUILD/qtlockedfile-2.4_1-opensource/qtlockedfile.pro
----------------------------------------
the problem is in mingw-qt-qmake. since it's put
mingw32-qt-qmake has
fedora-win32-cross
win32-g++-cross
but don't have win32-g++-fedora-cross.
if i use the in spec file version win32-g++-cross then another problem
happened during build:
----------------------------------
make[2]: Entering directory
`/builddir/build/BUILD/qtlockedfile-2.4_1-opensource/buildlib'
i686-w64-mingw32-g++ -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
--param=ssp-buffer-size=4 -mms-bitfields -O2 -Wall -DUNICODE
-DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB
-I"/usr/i686-w64-mingw32/sys
-root/mingw/include/QtCore"
-I"/usr/i686-w64-mingw32/sys-root/mingw/include" -I"../src" -I"release"
-I"/usr/lib/qt4/mkspecs/win32-g++-cross" -o release/qtlockedfile.o
../src/qtlockedfile.cpp
i686-w64-mingw32-g++ -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
--param=ssp-buffer-size=4 -mms-bitfields -O2 -Wall -DUNICODE
-DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB
-I"/usr/i686-w64-mingw32/sys
-root/mingw/include/QtCore"
-I"/usr/i686-w64-mingw32/sys-root/mingw/include" -I"../src" -I"release"
-I"/usr/lib/qt4/mkspecs/win32-g++-cross" -o release/qtlockedfile_unix.o
../src/qtlockedfile_unix.cpp
../src/qtlockedfile_unix.cpp: In member function 'bool
QtLockedFile::lock(QtLockedFile::LockMode, bool)':
../src/qtlockedfile_unix.cpp:70:18: error: aggregate
'QtLockedFile::lock(QtLockedFile::LockMode, bool)::flock fl' has
incomplete type and cannot be defined
../src/qtlockedfile_unix.cpp:74:38: error: 'F_RDLCK' was not declared in
this scope
../src/qtlockedfile_unix.cpp:74:48: error: 'F_WRLCK' was not declared in
this scope
../src/qtlockedfile_unix.cpp:75:23: error: 'F_SETLKW' was not declared
in this scope
../src/qtlockedfile_unix.cpp:75:34: error: 'F_SETLK' was not declared in
this scope
../src/qtlockedfile_unix.cpp:76:39: error: 'fcntl' was not declared in
this scope
../src/qtlockedfile_unix.cpp: In member function 'bool
QtLockedFile::unlock()':
../src/qtlockedfile_unix.cpp:100:18: error: aggregate
'QtLockedFile::unlock()::flock fl' has incomplete type and cannot be defined
../src/qtlockedfile_unix.cpp:104:17: error: 'F_UNLCK' was not declared
in this scope
../src/qtlockedfile_unix.cpp:105:31: error: 'F_SETLKW' was not declared
in this scope
../src/qtlockedfile_unix.cpp:105:44: error: 'fcntl' was not declared in
this scope
make[2]: *** [release/qtlockedfile_unix.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
`/builddir/build/BUILD/qtlockedfile-2.4_1-opensource/buildlib'
make[1]: *** [release] Error 2
make[1]: Leaving directory
`/builddir/build/BUILD/qtlockedfile-2.4_1-opensource/buildlib'
make: *** [sub-buildlib-make_default-ordered] Error 2
----------------------------------
--
Levente "Si vis pacem para bellum!"
12 years, 10 months
help with cmake macro
by Farkas Levente
hi,
i try to package opencv for mingw which use cmake. when i try to build
it i need to add a few params, but i can't do it, because:
%mingw_cmake "-DENABLE_OPENMP=1"
but during the build it runs:
/usr/bin/cmake -DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib
-DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include
-DLIB_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib
-DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share
-DCMAKE_SKIP_RPATH:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake ..
-DENABLE_OPENMP=1
as you can see the path is NOT the last param which cause problems:-)
actually i don't understand it since mingw32_cmake defined as:
%mingw32_cmake() %{mingw32_env} ; \
__mingw32_topdir=.; if ! test -f CMakeLists.txt; then
__mingw32_topdir=..; fi; \\\
%__cmake \\\
-DCMAKE_VERBOSE_MAKEFILE=ON \\\
-DCMAKE_INSTALL_PREFIX:PATH=%{mingw32_prefix} \\\
-DCMAKE_INSTALL_LIBDIR:PATH=%{mingw32_libdir} \\\
-DINCLUDE_INSTALL_DIR:PATH=%{mingw32_includedir} \\\
-DLIB_INSTALL_DIR:PATH=%{mingw32_libdir} \\\
-DSYSCONF_INSTALL_DIR:PATH=%{mingw32_sysconfdir} \\\
-DSHARE_INSTALL_PREFIX:PATH=%{mingw32_datadir} \\\
%{?_cmake_skip_rpath} \\\
-DBUILD_SHARED_LIBS:BOOL=ON \\\
-DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake \\\
$* $__mingw32_topdir
where the __mingw32_topdir is the last param so when it's called why not
the last param?
any help would be useful.
thanks.
--
Levente "Si vis pacem para bellum!"
12 years, 10 months
OCaml packages for mingw
by Jerome Benoit
Hello,
I've seen discussion on OCaml's integration in MinGW cross compilation
suite shipped in Fedora. What is the status of this work ? Is there
any repo where I can pull .spec file or SPRPMs ?
I'm very interested in helping 'cause after the first pass to port a
software written in OCaml to Windows, it's really a pain in the
ass (to first have just bootstrap Ocaml in Windows with all needed
libraries and then) maintain it.
http://repos.fedorapeople.org/ do not expose any work on MinGW too.
Cheers.
--
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
12 years, 10 months
rhel-6 mingw conclusions
by Farkas Levente
hi,
i try to collect here what i did to be able to rebuild the new mingw-64
toolchain on rhel-6. most of the modifications i made i'll shourtly
checkin into Erik's repo:
http://svn.openftd.org/svn/fedora_cross
first of all add the preamble always extended to the default:
-------------------------
%global __strip %{mingw_strip}
%global __objdump %{mingw_objdump}
%global _use_internal_dependency_generator 0
%global __find_requires %{mingw_findrequires}
%global __find_provides %{mingw_findprovides}
%global __debug_install_post %{mingw_debug_install_post}
-------------------------
even if the middle 3 not required on fedora.
replace all %define to %global (which should have to be fixed on the
page too:
https://fedoraproject.org/wiki/Packaging:MinGW_Future
- mingw-crt
update to 20110620 since d3dx9xof.h only checked in after 20110615.
unfortunately it's still not working ie the new d3dvideosink in
gstreamer-bad still not working (but i'm still trying:-)
also add mingw-w64-crt-autoconf.patch which is the diff between the
original and "autoreconf --install --force" on f15 so the autoreconf no
longer needed (since autotool too old on rhel-6).
- mingw-libtiff
drop all autotool run (it seems not really neded)
- mingw-sqlite
if-ed the dll move it doesn't seems to needed on rhel (i don't really
understand why needed on fedora).
- mingw-win-iconv
add versioned cmake BR since old cmake can't build it.
- none of the mingw-gstreamer* package be able to build with debug
subpackage!? and i don't know why! i always got error, but now it works
again!?
--
Levente "Si vis pacem para bellum!"
12 years, 10 months
[Bug 577951] Review Request: mingw32-wine-gecko - MinGW Gecko library required for Wine
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=577951
--- Comment #21 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> 2011-06-21 14:37:28 EDT ---
Very nice to see that you based this package on the new MinGW packaging
guidelines (https://fedoraproject.org/wiki/Packaging:MinGW_Future) !
Some small comments:
Please start the .spec file with these set of lines:
%global __strip %{mingw_strip}
%global __objdump %{mingw_objdump}
%define __debug_install_post %{mingw_debug_install_post}
And add a line with %{?mingw_debug_package} right before the start of the first
%package tag. This is needed to automatically extract debug information
I noticed you used the %{description} tag in some places. Last time I tried,
this didn't give the expected results, so you may need to manually add a real
description instead of this macro.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
12 years, 10 months
mingw-64 src
by Farkas Levente
hi,
what's the plan about the mingw64 source selection? i mean there're a
few source which can be choose as the base for the toolchain.
- automated daily svn snapshot build (choosen by Erik for his repo)
- or mingw64 releases with is still not too stable.
- there are another branch cygwin which use some strange versions:
1.0b-svn4214-1 which i can't found in the svn (but this branch has a
working d3d header files:-()
of course the best would be a stable 1.0 release...
--
Levente "Si vis pacem para bellum!"
12 years, 10 months
