Hi
After seeing such vigor discussion about vcdiff on windows I finely decided to find out what is really happening. The first step is compiling geany.
So I follow Cross Compile instruction on geany web page. 1) Here is script to fix pkgconfig prefix variables, that instruction suggested to write. (Maybe we should place it somewhere on geany web page and make link to it from Cross Compile page?)
I used used "configure" "make" approach to get geany.exe. Here is issues I encounter and patch for them.
1) scintilla/ScintillaGTK.cxx, Windows.h should be changed to windows.h since cross compiler is still case sensitive. This should be probably reported to Scintilla.
2) Does windows version need GEANY_PREFIX, GEANY_DATADIR, GEANY_LIBDIR, GEANY_LOCALEDIR? If so need to define them probably in configure.in. For now I commented them.
3) Using hardcoded i386-mingw32msvc as cross-compile target is not very nice. I replaced /usr/local/cross-tools/bin/i386-mingw32msvc-windres with $(host)-windres in makefile.am.
Also I used:
test "x$target" != "x${target##*mingw}";
to detect windows cross-compile, but perhaps ## syntax is bashism. Anyone know how to check it better?
4) Checks for unix domain socket and vte should be placed after mingw detection, since windows have no such things.
5) Windows doesn't have fnmatch, I replaced it's usage with modified function I found in one of the files. But this is really smell bad.
p.s I was able to run geany in wine, but something nasty happend with fonts. I see only rectangles. I guess I will find it tomorrow.
p.p.s. At download page http://geany.uvena.de/Download/Releases written that geany-0.13_setup.exe contains GTK 2.10, but installer said it is 2.12.
On Feb 18, 2008 6:25 PM, Yura Siamashka yurand2@gmail.com wrote:
If you just need to test for the general case of cross compiling, I think this should work:
[test "x${cross_compiling}" = "xyes"]
And then maybe something like:
case "${host_os}" in mingw*) # ... ;; esac
to test for mingw...
- Jeff
On Tue, 19 Feb 2008 02:25:38 +0200, Yura Siamashka yurand2@gmail.com wrote:
Hi,
thanks for the patch.
I'll sent a patch to the Scintilla mailing list.
On Windows, Geany is installed (and configured) to use relative paths. These macros are defined in src/makefile.win32, we should define them in src/Makefile.am for cross-compiling, too.
Yes, I used this because I didn't expect anyone else than me would use this and hardcoding the paths was just easier :D.
I'm not yet sure why this happens but fnmatch is available via liberty, IIRC. At least when I wrote the cross-compiling stuff, it worked. Right now, I have some other problems which prevent me from further testing, e.g. configure doesn't detect the host correctly. And I don't have the time to test further now. I applied your patch partyl, thanks and I will continue testing on Friday or Saturday.
p.s I was able to run geany in wine, but something nasty happend with fonts. I see only rectangles. I guess I will find it tomorrow.
Hehe, Geany for Windows in Wine on Linux ;-). I've no idea what went wrong there but I wouldn't spend too much time in solving problems in this environment...
Fixed, thanks.
Regards, Enrico
Hi
On Wed, 2008-02-20 at 13:38 +0100, Enrico Tröger wrote:
2 new changes:
1) src/Makefile.am - don't attach geany_LDFLAGS to AM_CFLAGS
2) Since without fnmatch.h we fail to build, I included fnmatch implementation that come internally with gtk.
On Thu, 21 Feb 2008 02:29:25 +0200, Yura Siamashka yurand2@gmail.com wrote:
Oops, thanks.
I'm still thinking it isn't necessary. I did compile it without any extra fnmatch code. I just have to remember and test how I did it. Give me a little time, please. If I'm wrong, I'll apply your patch.
Regards, Enrico
Hi
On Thu, 2008-02-21 at 17:26 +0100, Enrico Tröger wrote:
Well, the current situation is like this:
configure check for useable fnmatch.h, if it is not found. build will fail, unless fnmatch present in one of the dependant libs (I think that is why you are able to build geany on windows). But we don't check it sane way.
So, currently we just say: "nay, fnmatch check can't fail" and hope that fnmatch symbol will be in one of depend libs.
On Thu, 21 Feb 2008 23:23:10 +0200, Yura Siamashka yurand2@gmail.com wrote:
fnmatch is present in libitery.a. Because of these problems, I mentioned this in http://geany.uvena.de/Support/CrossCompile#libiberty
And I also mentioned the fnmatch when I wrote: "After that, you should have an executable in the src directory named geany.exe. If you got some linker errors like undefined reference to `_fnmatch' or undefined reference to `_lrealpath', you need another version of libiberty."
Unfortunately, the link to the working libitery.a.gz was broken but I fixed it and it should work again.
And I added your fix_pkgconfig.sh script on the cross-compile wiki page, thank you.
Well, I got my cross-compile setup working again and committed a bunch of changes. It's probably not yet perfect but it should be better: - some optimisations in src/Makefile.am - synced the list of Windows libraries to link against with the ones from makefile.win32 - removed unnecessary -I /usr/local/cross-tools from scintilla/Makefile.am - I had to replace $(host)-windres with $(host-alias)-windres. The variables have the following values on my system: host = i386-pc-mingw32 host_alias = i386-mingw32 So, $(host)-windres would be i386-pc-mingw32-windres but we need i386-mingw32-windres (without the "pc"). I'm not sure how portable this is, please test it whether it works on your machine.
There is still some more work needed in plugins/Makefile.am which isn't doesn't build any DLl's at all at the moment.
Regards, Enrico
Hi
On Fri, 2008-02-22 at 11:04 +0100, Enrico Tröger wrote:
On Thu, 21 Feb 2008 23:23:10 +0200, Yura Siamashka yurand2@gmail.com wrote:
Attached patch check for fnmatch presence in libitery for mingw and suggest to update it if it is not. Probably the same should be done for lrealpath?
It works, both host and host alias is "i586-pc-mingw32" on my machine.
On Fri, 22 Feb 2008 13:33:33 +0200, Yura Siamashka yurand2@gmail.com wrote:
Thanks Yura, committed.
lrealpath?
Hmm, we don't use lrealpath anymore. It was replaced by some better code some time ago. I will remove the note from the wiki page.
Hmmm, then you'll get "i586-pc-mingw32-windres", is this how your windres utility is called ?
Regards, Enrico
Hi
Hmmm, then you'll get "i586-pc-mingw32-windres", is this how your windres utility is called ?
yes, I builded gcc from sources, using script at CrossCompile page. I get:
/usr/local/cross-tools/bin/i586-pc-mingw32-gcc /usr/local/cross-tools/bin/i586-pc-mingw32-windres
At work I built cross compiler using gentoo crossdev package and it doesn't contains any "-pc-" part in filenames.
Best regards, Yura Siamashka
On Sat, 23 Feb 2008 19:24:09 +0200, Yura Siamashka yurand2@gmail.com wrote:
Ok, I guess host-alias will work then also on your PC at work.
Btw, your last was not yet committed as I told in the my last mail. The SVN isn't accessible right now. Once it's working again, I'll commit the patch.
Regards, Enrico
On Fri, 22 Feb 2008 11:04:21 +0100, Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
There is still some more work needed in plugins/Makefile.am which isn't doesn't build any DLl's at all at the moment.
if anyone wants to spend some time on this, attached is a patch (geany_crosscompile_plugins.patch) which should be basically be enough to build plugin DLLs when cross-compiling.
For some reason, this doesn't work out of box on my system. I'm not sure if it is a real error or if it is only related to my cross-compiling setup. The problem is, libtool doesn't detect the file format of libiberty.a correctly and so it refuses to link any shared library and you end up with static libraries only. I always get the following error message:
*** Warning: linker path does not have real file for library -liberty. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libiberty and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/local/cross-tools/usr/lib//libiberty.a
*** Warning: libtool could not satisfy all declared inter-library *** dependencies of module classbuilder. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag.
After some googling, I started to modify the created libtool ;-). I attached a patch for libtool which solves the problem, at least in some way. Apply it *after* you ran configure otherwise the configure script will overwrite the libtool script again. With this little change in the patch, dynamic linking will work. But patching libtool doesn't seem to be a reasonable solution, not even a workaround. So, if anyone has the time and some will to find and maybe solve the real cause for this troubles, feel free to do it and report any progress.
Regards, Enrico