Hey!
Since it has been a while since i last built git on interix, it didn't work out of the box for older interixen.
There are a few small changes required, which i hope should be not a big thing to get included in the git repo.
The removal of two previously required options from the Makefile is because of a special library (libsuacomp: [1]).
This library is required all over the place on interix, and provides those previously missing things. There are
others depending on this (gnulib, findutils, coreutils, ...) for interix support, and thus i think it should not
be a problem to depend on it, right?
May i ask for a review?
Thanks,
markus
Hi,
mduft@gentoo.org wrote:
quoted hunk
--- a/compat/fnmatch/fnmatch.c
+++ b/compat/fnmatch/fnmatch.c
@@ -25,6 +25,7 @@
# define _GNU_SOURCE 1
#endif
+#include <unistd.h>
#include <errno.h>
Given that we are touching this file anyway, how about relying on
git-compat-util for this?
That way, there is no need to debug feature test macros, order of
#includes, etc. Untested.
-- >8 --
Subject: compat/fnmatch: use git-compat-util.h for system headers
Finding the right feature test macros and ordering of #includes to
get the desired functionality from all operating systems can be a big
pain. Take advantage of the debugging already done and avoid future
churn by using git's usual git-compat-util for this.
In particular, the current fnmatch.c doesn't #include anything that
ought to provide NULL unless HAVE_STRING_H is defined, and it fails to
compile on Interix because of this. Other platforms must have been
getting the macro through another header.
To make this code easier to reuse and to simplify future automated
merges from upstream, still keep the old #includes, just disabled with
"#if 0".
Reported-by: Markus Duft <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---
Maybe the old #includes after #include-ing git-compat-util should be
left uncommented because harmless.
compat/fnmatch/fnmatch.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
index 14feac7..4bf3b5c 100644
--- a/compat/fnmatch/fnmatch.c
+++ b/compat/fnmatch/fnmatch.c
@@ -16,6 +16,9 @@
write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
+#include "git-compat-util.h"
+
+#if 0
#if HAVE_CONFIG_H
# include <config.h>
#endif@@ -46,6 +49,7 @@
# include <wchar.h>
# include <wctype.h>
#endif
+#endif
/* Comment out all this code if we are using the GNU C Library, and are not
actually compiling the library itself. This code is part of the GNU C--
1.7.5.1
On 05/25/11 16:15, mduft@gentoo.org wrote:
(sorry for actually replying to the wrong mail - wasn't subscribed to the list (but am now.))
quoted
The removed options are obsolete, because interix support now
depends on libsuacomp.
and linkage with -lsuacomp happens automatically without any change in the
Makefile for anybody? Just asking, as I do not have an access to (nor any
particular desire to get an access to) an Interix to figure it out myself,
and the only think I care about in this patch is if it helps only your
installation or it will help everybody who has Interix but not necessarily
with the same set of additional configuration as you have.
Yes. suacomp installs itself as libc.{a,so}. Of course the path to the suacomp prefix needs to be told to the compiler. Without it, interix (at least the newer versions) are near unusable, because of a whole lot of bugs M$ won't fix (as usual...). Suacomp can be installed manually by whoever likes to, and is included in the Gentoo Prefix project automatically (which is my target). I guess without Gentoo Prefix there'd be another whole lot of things missing to build git anyway (haven't tried). Gentoo Prefix also automatically get's all paths right, etc.
Currently, suacomp is already required for things like coreutils, perl, python, openssh, findutils, etc., etc. to work correctly, if not build at all...
Hope that explains some, sorry for not doing so at first :)
Regards, Markus
quoted
Signed-off-by: Markus Duft <mduft <at> gentoo.org>
(still not getting mail from the list, so copied from the archive...).
Markus Duft <mduft <at> gentoo.org> writes:
[snip]
quoted
Yes. suacomp installs itself as libc.{a,so}. Of course the path to the
suacomp prefix needs to be told to the compiler. Without it, interix (at
least the newer versions) are near unusable,...
You are much more familiar with Interix than I am, and if you were the
only person who uses Interix with git, I would buy that argument
unconditionally.
How has one built and used git before suacomp days? Are these users
extinct? Are there users who do not still use suacomp and for whatever
reason do not want to use it, but still want to use git?
I did start the git porting when i ported Gentoo Prefix [1] to interix. I only ever tried to build it in there, and i actually don't think that there is any other build-case for interix (ATM). Maybe someday someone has the great idea of building/using git without Gentoo Prefix (good luck .. :)), but currently this is (AFAICT) not the case. In Gentoo Prefix in turn, suacomp is always there, on interix, and all versions are supported right now (interix 3.5 was not, but i did the work). Also, the compiler and linker are set up accordingly there.
so, in order:
1) yes, i did in gentoo prefix, which now uses suacomp
2) yes, with the appearence of suacomp in gentoo prefix
3) if a user of gentoo prefix does not yet have suacomp,
he/she will get upgraded automatically. i do not know
of other users, and believe they don't exist.
What I am getting at is that I have to come up with a description in the
release notes, and I cannot decide what the entry for this change should
say, and if I can stand behind that statement.
Here is one version, based on my reading of what you said so far:
* The build procedure for Interix now requires use of suacomp. Older
versions of Interix that are incompatible with suacomp are no longer
supported. The Makefile does not automatically tell "the path to the
suacomp prefix" to the compiler, so you would need to do that yourself.
The part with incompatible is no longer true. i tried building git on all interix versions, and it works fine. I feel, that if a user really installs plain interix, wan't git and isntalls suacomp himself, he/she will be power-user enough to manage and tell the build about some include/lib paths.
Doesn't sound pretty, and I hesitate to stand behind such a statement.
Abandoning obsoleted versions of obscure platform nobody cares about is
fine, but at least we should make it clear who are being abandoned by
saying which version. Also "needs to be told to the compiler" part needs
some end-user explanation in Makefile ("set HAVE_SUACOMP=/usr/lib/suacomp
when building on/for Interix", or something).
Hm. suacomp is designed to be completely transparent to (nearly) everything involved in building a package. It should be part of the suacomp setup process to get it into the compiler/linker (by, for example, creating shell script wrappers around compiler/linker, much like colorgcc et. al.). If at all, i'd only set a HAVE_SUACOMP=YesPlease, and based on that, default some symbols to different values (exactly those that the 1/2 patch modifies).
Here is another possible version (you would need to update your patch to
support both):
* On Interix, it is preferrable to use suacomp to build git, but the old
way is still supported. Give HAVE_SUACOMP=/path/to/suacomp to Make (or
override it in your config.mak) when building git.
The "old way" was only supported on interix 6.0, as i found out. both interix 5.2 and 3.5 needed at least some additional workarounds, which are now gone with suacomp. I don't think that it would be worth the work (although i'd happily do it, if you want), to support an "old way" which has not a single advantage, and doesn't event work everywhere.
That is more easily justifiable, but I cannot tell from this exchange with
you how important to keep supporting the old way is (or if it is even
possible).
It is possible, but as i said, i don't think it is worth it.
However we proceed: thanks for contemplating about such an exotic platform. i really appreciate it!
Markus