This is the ebuild for the cross-compiled wxWidgets libraries. The first bugfix patch is applied during the ebuild,but I had trouble with getting portage to work with _p1 in the name so the ebuild name isn't entirely accurate. The ebuild is quite similar to the old wx-xmingw-2.4.2.ebuild Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 67248 [details] ebuild for the latest cross compiled wxWidgets
Changed source tarball to .bz2 to eliminate redundant downloads with wxGTK-2.6.1 --- wx-xmingw-2.6.1.ebuild 2005-08-30 18:09:41.545179960 +1200 +++ wx-xmingw-2.6.1-r1.ebuild 2005-08-31 09:38:53.667979984 +1200 @@ -5,7 +5,7 @@ DESCRIPTION="Win32 version of wxWidgets for xmingw cross-compiler" SRC_URI=" - mirror://sourceforge/wxwindows/wxWidgets-${PV}.tar.gz + mirror://sourceforge/wxwindows/wxWidgets-${PV}.tar.bz2 ftp://biolpc22.york.ac.uk/pub/${PV}/wxWidgets-${PV}-Patch01.zip" HOMEPAGE="http://www.wxwidgets.org/" LICENSE="wxWinLL-3"
*** Bug 110923 has been marked as a duplicate of this bug. ***
checking whether i386-mingw32msvc-c++ accepts -g... no checking if the C++ compiler requires -ext o... configure: error: cannot figure out if compiler needs -ext o: cannot compile
Anton, I think you emerged xmingw-gcc only once and therefore got no C++ compiler. Emerge xmingw-gcc once more and try again to emerge wx-xmingw. On my machine the the ebuild breaks with: ./bk-deps i386-mingw32msvc-c++ -c -o netdll_protocol.o -I.pch/wxprec_netdll -D__WXMSW__ -I./src/tiff -I./src/jpeg -I./src/png -I./src/zlib -I./src/regex -I./src/expat/lib -DwxUSE_GUI=0 -DWXUSINGDLL -DWXMAKINGDLL_NET -DWX_PRECOMP -DNO_GCC_PRAGMA -D__WXDEBUG__ -Ilib/wx/include/i386-mingw32msvc-msw-ansi-debug-2.6 -I./include -g -O0 -I/opt/xmingw/i386-mingw32msvc/include -mthreads -Wall -Wno-ctor-dtor-privacy ./src/common/protocol.cpp ./src/common/http.cpp:1: sorry, unimplemented: had to relocate PCH ./src/common/http.cpp:1: confused by earlier errors, bailing out make: *** [netdll_http.o] Error 1 make: *** Waiting for unfinished jobs.... I am no expert in cross-compiling or wxWidgets, but I will have a closer look. Anyway, if anyone has an idea, I am glad for a hint. ;-) dev-util/xmingw-binutils-2.15.90.0.2 dev-util/xmingw-gcc-3.4.4 dev-util/xmingw-runtime-3.5 dev-util/xmingw-w32api-3.1
(In reply to comment #5) > Anton, I think you emerged xmingw-gcc only once and therefore got no C++ > compiler. Emerge xmingw-gcc once more and try again to emerge wx-xmingw. oh.... i've missed this. thnx, now it compiles fine.
Ok, I found the problem. Seems, that pre-compiled headers do not always work with gcc, there are some problems left. In this case the problem was triggered by the address space randomization in current kernels (from 2.6.12 upwards), which is incompatible to gcc-3.4.x implementation of PCHs: http://gcc.gnu.org/ml/gcc/2005-07/msg00851.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14206 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14400 Workaround is to disable the randomization with # echo 0 > /proc/sys/kernel/randomize_va_space or to disable the use of pre-compiled headers in the configure (--disable-precomp-headers). The attached ebuild emerges fine now and seems to work without problems on my machine.
Created attachment 77346 [details] ebuild for wx-xmingw-2.6.2 Ebuild for wx-Widgets-2.6.2, based on the one for 2.6.1
The attached ebuild for wx-xmingw-2.6.2 is based on the one for 2.6.1. I made two changes: 1) the "gdb" USE flag had no effect as it was used with `use_enable gdb` which outputs "--enable-gdb" if "gdb" is in use. Unfortunately this does not work, as the configure flag is called "--enable-debug_gdb". Fixed in wx-xmingw-2.6.2.ebuild 2) if --enable-debug_gdb is used, the latest stable xmingw-binutils are too old (they miss a pseudo-op (.secrel32) to generate 32 bit section relative relocations on pe[i]-i386; required for that target's DWARF 2 support). Therefore, if USE flag "gdb" is enabled, a dependency for ">=dev-util/xmingw-binutils-2.15.94.20050118.1" is added. Works on my system, hopefully on yours too. Have fun! :-)
dev-libs/wx-xmingw needs to be punted, not updated
Any reason?
why do you need a special ebuild ? create a generic wxwidgets ebuild and cross-compile that like you would any other package
Maybe there is a better way of doing it. But the ebuild is already in the portage and I think, that before you will remove it - you should show a good, working, documented repleacement. But I also think that cross-compiling should be somehow organized.
it's a waste of time to continue developing this we are punting all of the xming packages because they dont belong in the tree
Ok, maybe waste of time for people, that are not using them, but what with people that are using this ebuilds? Do you have any good alternative for them? If you are just going to stop supporting this kind of utilities in gentoo maybe I will move this ebuilds to my homepage.
Bug 129598 takes care of everything
Ok, I'm reading about crossdev for the first time, and maybe it's a better way. I'm only afraid that you will remove these ebuilds BEFORE this packages will be supported in crossdev. That's it.
there is no such thing as "supported in crossdev" crossdev generates a cross-compiler and that's it; it's the same exact thing as if you did `emerge dev-util/xmingw-runtime` so all of the xmingw packages could be punted right now without any functionality loss
So the crossdev script is making xmingw-runtime, xmingw-gcc, xmingw-win32, xmingw-binutils obsolete... but not wx-xmingw. wx-xmingw is an ebuild that will generate cross-compiled wxWidgets library for win32 environment and install it in the filesystem, so you can cross-compile packages that depends on it and manage it (update, uninstall). And it is win32-specific, because it uses wxMSW tarball. This is the same as you want to remove wxGTK ebuild because there is an ebuild for gcc. If crossdev script is not giving us true replacement for wx-xmingw ebuild this ebuild should stay because people wanted it, created it, it was placed in the portage and people use it (I can't check it but I think so). Maybe it will be more clear if you write us how to cross-compile wxWidgets for win32 using the "new method" when you remove wx-xmingw ebuild?
it is not win32-specific and that's the point the correct solution is to write a general wxwindows ebuild and not clutter the tree with target-specific ebuilds
Is it possible to have this general ebuild emerged twice (once for standard system library, second time for cross-compilation)? The lists of emerged packages are kept separately? If it is like that this is a good idea, but we should remove old ebuild AFTER a new one will be ready. Is there any good documentation about these issues? I can't find any more that crossdev --help.
yes and no ... that's a different topic entirely unrelated to wxwindows
(In reply to comment #20) > it is not win32-specific and that's the point It is win32-specific in the sense that a completely different set of sources is compiled. Instead of the src/gtk subdir of the sources, src/msw subdir needs to be built by passing --with-msw to the configure script. I assume I can check cross-compilation and pass it if I detect mingw32. > the correct solution is to write a general wxwindows ebuild and not clutter the > tree with target-specific ebuilds The current wx package is named wxGTK, because it IS the GTK port, always referred to as wxGTK upstream and by all of its users. It is not named wxWidgets to support other targets on the tree one day. That's why the wxlib.eclass was introduced. wxGTK, wxMotif, wxX11, and so on. These do not use a target-specific cross-compiler, but the normal gcc. It doesn't make sense to have wxMSW be compiled from wxGTK package (renamed or not to wxWidgets) once more ports are introduced to the tree. Personally I'm not sure why wxMSW (wx-xmingw) should be in the portage tree (as a separate target or as a crossdev capable ebuild), but I haven't explored much the set of xmingw32 packages yet.
It is ok for me to remove the ebuild if it won't take away any good functionality from gentoo that people use now. It is possible that you remove the ebuild and later we will notice, that something is not possible using crossdev (for example having wxGTK and wxMSW installed at the same time) so I think that crossdev features topic is releated to this issue.
*** Bug 149291 has been marked as a duplicate of this bug. ***
xmingw packages are masked now. I've installed crossdev and prepared mingw32 compiler but I can't find any resonable documentation how to crosscompile other ebuilds using crossdev and how to prepare wxWidgets ebuild for it.
Created attachment 101195 [details] new wxMSW-2.6.2 ebuild working with a crossdev mingw32 build This ebuild can be installed in connection with a crossdev generated mingw32 compiler. You need some patches from the wxGTK ebuild.
It seems as if portage wants to strip the generated libs -- using the normal strip command. Does somebody know how to stop portage from doing this OR how to tell it to use mingw32-strip?
Created attachment 101203 [details] fixed cross-mingw32/wxMSW ebuild removed stripping from features, adjusted prefix
perhaps the proper solution is to punt all this mingw cruft to an overlay ... i'd be perfectly happy with that and we could leave it up to users to maintain it without worrying about crap polluting the tree
Move stuff to new alias
Re-reassigning, sorry for the bugspam
looks like this was dropped long time ago from the tree
