latest clone/pull of git.git problems with setlinebuf.

latest clone/pull of git.git problems with setlinebuf.

[Boyd Lynn Gerber]

Hello,

I just noticed that setlinebuf is coming back as undefined when trying to 
build the lastest version.

on UnixWare 7.1.4 I get

     LINK git-var
     CC daemon.o
UX:acomp: WARNING: "daemon.c", line 485: end-of-loop code not reached
     LINK git-daemon
Undefined                       first referenced
symbol                              in file
setlinebuf                          daemon.o
UX:ld: ERROR: Symbol referencing errors. No output written to git-daemon
gmake: *** [git-daemon] Error 1


and on OpenServer 6.0 I get

     LINK git-http-push
     CC daemon.o
UX:acomp: WARNING: "daemon.c", line 485: end-of-loop code not reached
     LINK git-daemon
Undefined                       first referenced
symbol                              in file
setlinebuf                          daemon.o
UX:ld: ERROR: Symbol referencing errors. No output written to git-daemon
gmake: *** [git-daemon] Error 1

So the new behavior breaks things.  On UnixWare 7.1.4 there is a 
/usr/ucb/cc but when I use it much more breaks.  It is better to use the 
/usr/bin/cc.

Can we please revert the patch that breaks this or provide a better fix. 
The older methods at least worked.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: latest clone/pull of git.git problems with setlinebuf.

[Boyd Lynn Gerber]

On Wed, 3 Sep 2008, Boyd Lynn Gerber wrote:
> I just noticed that setlinebuf is coming back as undefined when trying to 
> build the lastest version.

I did

git clone git://git.kernel.org/pub/scm/git/git.git git

cd git/
gmake configure
CC=cc CXX=CC ./configure

And then I get the errors.

> on UnixWare 7.1.4 I get
>
>    LINK git-var
>    CC daemon.o
> UX:acomp: WARNING: "daemon.c", line 485: end-of-loop code not reached
>    LINK git-daemon
> Undefined                       first referenced
> symbol                              in file
> setlinebuf                          daemon.o
> UX:ld: ERROR: Symbol referencing errors. No output written to git-daemon
> gmake: *** [git-daemon] Error 1
>
>
> and on OpenServer 6.0 I get
>
>    LINK git-http-push
>    CC daemon.o
> UX:acomp: WARNING: "daemon.c", line 485: end-of-loop code not reached
>    LINK git-daemon
> Undefined                       first referenced
> symbol                              in file
> setlinebuf                          daemon.o
> UX:ld: ERROR: Symbol referencing errors. No output written to git-daemon
> gmake: *** [git-daemon] Error 1
>
> So the new behavior breaks things.  On UnixWare 7.1.4 there is a /usr/ucb/cc 
> but when I use it much more breaks.  It is better to use the /usr/bin/cc.
>
> Can we please revert the patch that breaks this or provide a better fix. The 
> older methods at least worked.

I really hate getting everything working only to then have another 
break-age from master on a pull.  Can we please try to keep some 
compatitbility with other non linux OS's.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: latest clone/pull of git.git problems with setlinebuf.

[Avery Pennarun]

On Wed, Sep 3, 2008 at 9:10 PM, Boyd Lynn Gerber <gerberb@zenez.com> wrote:
> I really hate getting everything working only to then have another break-age
> from master on a pull.  Can we please try to keep some compatitbility with
> other non linux OS's.

Well, it's kind of unavoidable; presumably most of the developers
don't have access to a UnixWare system, and thus have no idea if their
patches will break compatibility with it.

Perhaps what you need is an autobuilder running on UnixWare that will
build Junio's pu and next branches, so that you can report problems
before they make it all the way into master.

Hey, what a coincidence!  I have just what you need! :)
http://marc.info/?l=git&m=122015205123247&w=2

Have fun,

Avery

Re: latest clone/pull of git.git problems with setlinebuf.

[Boyd Lynn Gerber]

On Wed, 3 Sep 2008, Avery Pennarun wrote:
> On Wed, Sep 3, 2008 at 9:10 PM, Boyd Lynn Gerber <gerberb@zenez.com> wrote:
>> I really hate getting everything working only to then have another break-age
>> from master on a pull.  Can we please try to keep some compatitbility with
>> other non linux OS's.
>
> Well, it's kind of unavoidable; presumably most of the developers
> don't have access to a UnixWare system, and thus have no idea if their
> patches will break compatibility with it.

I offer free access to the OpenServer 6.0, UnixWare 7.1.4 and OpenServer 
5.0.7 to oss developers.  The only condition is the use them for OSS 
development.  Free access is only for non commercial developement.  I do 
have paid access for non OSS.

> Perhaps what you need is an autobuilder running on UnixWare that will
> build Junio's pu and next branches, so that you can report problems
> before they make it all the way into master.
>
> Hey, what a coincidence!  I have just what you need! :)
> http://marc.info/?l=git&m=122015205123247&w=2

I cloned the repo when you announced it.  I was going to get the latest 
git master running and then use them.  I have them.  I hope to have them 
running in the next while.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: latest clone/pull of git.git problems with setlinebuf.

[Junio C Hamano]

Boyd Lynn Gerber <gerberb@zenez.com> writes:

> Hello,
>
> I just noticed that setlinebuf is coming back as undefined when trying
> to build the lastest version.
>
> on UnixWare 7.1.4 I get
>
>     LINK git-var
>     CC daemon.o
> UX:acomp: WARNING: "daemon.c", line 485: end-of-loop code not reached
>     LINK git-daemon
> Undefined                       first referenced
> symbol                              in file
> setlinebuf                          daemon.o
> UX:ld: ERROR: Symbol referencing errors. No output written to git-daemon
> gmake: *** [git-daemon] Error 1

Ah, ok.  I should have noticed that setlinebuf() was outside POSIX (it is
not usable on older BSDs either).

Let's see if we can replace it with setvbuf() which is POSIX.

---
 daemon.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git c/daemon.c w/daemon.c
index 23278e2..7f2743a 100644
--- c/daemon.c
+++ w/daemon.c
@@ -1083,7 +1083,8 @@ int main(int argc, char **argv)
 		openlog("git-daemon", LOG_PID, LOG_DAEMON);
 		set_die_routine(daemon_die);
 	} else
-		setlinebuf(stderr); /* avoid splitting a message in the middle */
+		/* avoid splitting a message in the middle */
+		setvbuf(stderr, NULL, _IOLBF, 0);
 
 	if (inetd_mode && (group_name || user_name))
 		die("--user and --group are incompatible with --inetd");

Re: latest clone/pull of git.git problems with setlinebuf.

[Boyd Lynn Gerber]

On Wed, 3 Sep 2008, Junio C Hamano wrote:
> Boyd Lynn Gerber <gerberb@zenez.com> writes:
>> I just noticed that setlinebuf is coming back as undefined when trying
>> to build the lastest version.
>>
>> on UnixWare 7.1.4 I get
>>
>>     LINK git-var
>>     CC daemon.o
>> UX:acomp: WARNING: "daemon.c", line 485: end-of-loop code not reached
>>     LINK git-daemon
>> Undefined                       first referenced
>> symbol                              in file
>> setlinebuf                          daemon.o
>> UX:ld: ERROR: Symbol referencing errors. No output written to git-daemon
>> gmake: *** [git-daemon] Error 1
>
> Ah, ok.  I should have noticed that setlinebuf() was outside POSIX (it is
> not usable on older BSDs either).
>
> Let's see if we can replace it with setvbuf() which is POSIX.

This fixes the problem. on both OS's.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: latest clone/pull of git.git problems with setlinebuf.

[Junio C Hamano]

Boyd Lynn Gerber <gerberb@zenez.com> writes:

> On Wed, 3 Sep 2008, Junio C Hamano wrote:
> ...
>> Ah, ok.  I should have noticed that setlinebuf() was outside POSIX (it is
>> not usable on older BSDs either).
>>
>> Let's see if we can replace it with setvbuf() which is POSIX.
>
> This fixes the problem. on both OS's.

By the way, have you actually exercised the codepath, or does your above
"fixes" mean "compiles"?

I knew it would compile on a system with POSIX setvbuf(), but I was unsure
about the size argument.  I know for glibc giving <NULL, 0> would be
equivalent to setlinebuf(), but POSIX itself leaves what exactly happens
to the size argument quite vague, saying only "otherwise [when buf is a
null pointer], size may determine the size of a buffer allocated by the
setvbuf() function."  Does size=0 mean it allocates very little, and while
it tries to line buffer the output, because the buffer is so small that it
fails to buffer an entire line causing early flushing of the stream?

Re: latest clone/pull of git.git problems with setlinebuf.

[Boyd Lynn Gerber]

On Wed, 3 Sep 2008, Junio C Hamano wrote:
> Boyd Lynn Gerber <gerberb@zenez.com> writes:
>> On Wed, 3 Sep 2008, Junio C Hamano wrote:
>>> Ah, ok.  I should have noticed that setlinebuf() was outside POSIX (it is
>>> not usable on older BSDs either).
>>>
>>> Let's see if we can replace it with setvbuf() which is POSIX.
>>
>> This fixes the problem. on both OS's.
>
> By the way, have you actually exercised the codepath, or does your above
> "fixes" mean "compiles"?
>
> I knew it would compile on a system with POSIX setvbuf(), but I was 
> unsure about the size argument.  I know for glibc giving <NULL, 0> would 
> be equivalent to setlinebuf(), but POSIX itself leaves what exactly 
> happens to the size argument quite vague, saying only "otherwise [when 
> buf is a null pointer], size may determine the size of a buffer 
> allocated by the setvbuf() function."  Does size=0 mean it allocates 
> very little, and while it tries to line buffer the output, because the 
> buffer is so small that it fails to buffer an entire line causing early 
> flushing of the stream?

I only compiled it.  I am debuging some test errors.  I did a gmake test

This is the test that fails.  Everything before it passes.

*   ok 41: very long name in the index handled sanely
* fixed 1 known breakage(s)
* still have 1 known breakage(s)
* passed all remaining 40 test(s)
*** t0001-init.sh ***
...
*   ok 9: GIT_DIR & GIT_WORK_TREE (2)
* FAIL 10: reinit


                 (
                         unset GIT_CONFIG GIT_WORK_TREE GIT_CONFIG

                         mkdir again &&
                         cd again &&
                         git init >out1 2>err1 &&
                         git init >out2 2>err2
                 ) &&
                 grep "Initialized empty" again/out1 &&
                 grep "Reinitialized existing" again/out2 &&
                 >again/empty &&
                 test_cmp again/empty again/err1 &&
                 test_cmp again/empty again/err2

* FAIL 11: init with --template

                 mkdir template-source &&
                 echo content >template-source/file &&
                 (
                         mkdir template-custom &&
                         cd template-custom &&
                         git init --template=../template-source
                 ) &&
                 test_cmp template-source/file template-custom/.git/file

*   ok 12: init with --template (blank)
* failed 2 among 12 test(s)
gmake[2]: *** [t0001-init.sh] Error 1


--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

Re: latest clone/pull of git.git problems with setlinebuf.

[Boyd Lynn Gerber]

On Wed, 3 Sep 2008, Boyd Lynn Gerber wrote:
> On Wed, 3 Sep 2008, Junio C Hamano wrote:
>> Boyd Lynn Gerber <gerberb@zenez.com> writes:
>>> On Wed, 3 Sep 2008, Junio C Hamano wrote:
>>>> Ah, ok.  I should have noticed that setlinebuf() was outside POSIX (it is
>>>> not usable on older BSDs either).
>>>> 
>>>> Let's see if we can replace it with setvbuf() which is POSIX.
>>> 
>>> This fixes the problem. on both OS's.
>> 
>> By the way, have you actually exercised the codepath, or does your above
>> "fixes" mean "compiles"?
>> 
>> I knew it would compile on a system with POSIX setvbuf(), but I was unsure 
>> about the size argument.  I know for glibc giving <NULL, 0> would be 
>> equivalent to setlinebuf(), but POSIX itself leaves what exactly happens to 
>> the size argument quite vague, saying only "otherwise [when buf is a null 
>> pointer], size may determine the size of a buffer allocated by the 
>> setvbuf() function."  Does size=0 mean it allocates very little, and while 
>> it tries to line buffer the output, because the buffer is so small that it 
>> fails to buffer an entire line causing early flushing of the stream?
>
> I only compiled it.  I am debuging some test errors.  I did a gmake test
>
> This is the test that fails.  Everything before it passes.

...
*   still broken 4: pretend we have a known breakage
*   FIXED 5: pretend we have fixed a known breakage
...

> *   ok 41: very long name in the index handled sanely
> * fixed 1 known breakage(s)
> * still have 1 known breakage(s)
> * passed all remaining 40 test(s)
> *** t0001-init.sh ***
> ...
> *   ok 9: GIT_DIR & GIT_WORK_TREE (2)
> * FAIL 10: reinit
>
>
>                (
>                        unset GIT_CONFIG GIT_WORK_TREE GIT_CONFIG
>
>                        mkdir again &&
>                        cd again &&
>                        git init >out1 2>err1 &&
>                        git init >out2 2>err2
>                ) &&
>                grep "Initialized empty" again/out1 &&
>                grep "Reinitialized existing" again/out2 &&
>                >again/empty &&
>                test_cmp again/empty again/err1 &&
>                test_cmp again/empty again/err2
>
> * FAIL 11: init with --template
>
>                mkdir template-source &&
>                echo content >template-source/file &&
>                (
>                        mkdir template-custom &&
>                        cd template-custom &&
>                        git init --template=../template-source
>                ) &&
>                test_cmp template-source/file template-custom/.git/file
>
> *   ok 12: init with --template (blank)
> * failed 2 among 12 test(s)
> gmake[2]: *** [t0001-init.sh] Error 1

I have now inclulded everything in gmake test that was not an OK.  I hope 
this answers your questions.

What I should have said is that I have not used it outside of gmake and 
gmake test.

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047