Hi,
I've read [1] recently, there's been some QNX port being initiated. Does that
involve also old versions of QNX 4?
Since we are using QNX both internally and for our customers we started porting
Git on QNX ourselves some time ago and we do have some experiences. Basically,
it's possible to
"David Ondřich" writes:
jch: redirecting to the guilty party ;-)
> I've read [1] recently, there's been some QNX port being
> initiated. Does that involve also old versions of QNX 4?
>
> Since we are using QNX both internally and for our customers we
> started porting Git on QNX ourselves some t
Junio C Hamano writes:
> "David Ondřich" writes:
> > I've read [1] recently, there's been some QNX port being
> > initiated. Does that involve also old versions of QNX 4?
No, I haven't been working on QNX 4 support. I've been targeting QNX 6.3.2,
with a little testing on QNX 6.5.0. I doubt wha
Hi,
sorry for long delay, I was busy on some important project so far. However,
we’ve found out really bad thing recently.
On Feb 21, 2013, at 7:04 PM, "Kraai, Matt" wrote:
> Junio C Hamano writes:
>> "David Ondřich" writes:
>>> I've read [1] recently, there's been some QNX port being
>>> init
Hi,
Here is a small patch with QNX build improvements:
1) Rename tar.h to tar_git.h. Latest QNX versions have system tar.h
header according to
http://pubs.opengroup.org/onlinepubs/009696699/basedefs/tar.h.html ,
to avoid inclusion of another tar.h, original header was renamed.
2) Rename fnmatch.h
Hello,
> Here is a small patch with QNX build improvements:
>
> 1) Rename tar.h to tar_git.h. Latest QNX versions have system tar.h
> header according to
> http://pubs.opengroup.org/onlinepubs/009696699/basedefs/tar.h.html ,
> to avoid inclusion of another tar.h, original header was renamed.
> 2)
Mike Gorchak writes:
> Hello,
>
>> Here is a small patch with QNX build improvements:
>>
>> 1) Rename tar.h to tar_git.h. Latest QNX versions have system tar.h
>> header according to
>> http://pubs.opengroup.org/onlinepubs/009696699/basedefs/tar.h.html ,
>> to avoid inclusion of another tar.h, or
>>> 2) Rename fnmatch.h to fnmatch_gnu.h and fnmatch.c to fnmatch_gnu.c to
>>> avoid inclusion of system fnmatch.h header in case if -I/usr/include
>>> path is specified before -Icompat/fnmatch. Which is common situation.
> As to the substance, I am fairly negative about the approach this
> patch t
Mike Gorchak writes:
> CFLAGS="-I/usr/qnxVVV/include" LDFLAGS="-I/usr/qnxVVV/lib" ./configure
> --prefix=/usr
Oh, I didn't notice that, but the definition of ALL_CFLAGS may be
what is wrong. It allows CFLAGS to come before BASIC_CFLAGS that
adds -Icompat/, which goes against the whole point of
Junio C Hamano writes:
> Mike Gorchak writes:
>
>> CFLAGS="-I/usr/qnxVVV/include" LDFLAGS="-I/usr/qnxVVV/lib" ./configure
>> --prefix=/usr
>
> Oh, I didn't notice that, but the definition of ALL_CFLAGS may be
> what is wrong. It allows CFLAGS to come before BASIC_CFLAGS that
> adds -Icompat/, w
Hi Junio,
> Swapping the order between CFLAGS and BASIC_CFLAGS in ALL_CFLAGS may
> be a good change for that reason as well.
This sounds very reasonable.
> In any case, I won't take a patch to rename source files left and
> right only to work around name collisions with random system header
> fi
Hi Mike,
Mike Gorchak wrote:
> diff --git a/config.mak.uname b/config.mak.uname
> index 8743a6d..2d42ffe 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -527,14 +527,21 @@ ifeq ($(uname_S),QNX)
> HAVE_STRINGS_H = YesPlease
> NEEDS_SOCKET = YesPlease
> NO_FNMATCH_CAS
Hi,
On Tue, Feb 26, 2013 at 12:25 PM, Matt Kraai wrote:
> I didn't realize that QNX 6.3.2 provided getpagesize. Its header
> files don't provide a prototype, so when I saw the warning, I assumed
> it wasn't available. Since NO_GETPAGESIZE is only used by QNX, if
> it's OK to reintroduce the war
> Is there a point to the version checking? I don't know that anyone
> has tried to build Git on QNX 4, so adding a case for it seems
> misleading.
getpagesize() was introduced in QNX 6.4.1, it is present in QNX 6.5.0
also. So at least for this version checking is requied.
> I didn't realize tha
> I don't think it's a good idea to just enable thread support. On QNX,
> once a process creates a thread, fork stops working. This breaks
> commands that create threads and then try to run other programs, such
> as "git fetch" with an https remote. If threads are enabled, I think
> that the use
Hi,
Please include me in the Cc field, since I'm not subscribed to the
list.
Mike Gorchak wrote:
> Do you have a testcase for this (without using git codebase)? I wrote
> numerous resource managers since QNX 6.0 using threads and fork()s for
> daemonization in different order and never experience
> If I remove the call to pthread_create, it doesn't output anything and
> exits successfully.
I see. Most resource managers use procmgr_daemon(), which has no such
limitation. Anyway, as far as I can see current git sources do not use
fork together with pthread, except for daemonize() function.
-
Am 26.02.2013 21:32, schrieb Mike Gorchak:
>> If I remove the call to pthread_create, it doesn't output anything and
>> exits successfully.
>
> I see. Most resource managers use procmgr_daemon(), which has no such
> limitation. Anyway, as far as I can see current git sources do not use
> fork toge
On Tue, Feb 26, 2013 at 10:32:16PM +0200, Mike Gorchak wrote:
> I see. Most resource managers use procmgr_daemon(), which has no such
> limitation. Anyway, as far as I can see current git sources do not use
> fork together with pthread, except for daemonize() function.
If threads are enabled, git
19 matches
Mail list logo
