threads / discuss / 15367

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

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

## tl;dr

9 messages between Sep 4, 2008 and Sep 4, 2008.

replies: 8people: 3as markdown or json

Boyd Lynn Gerber· Sep 4, 2008, 01:04 UTC · lore
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

Boyd Lynn Gerber· Sep 4, 2008, 01:10 UTC · re: Boyd Lynn Gerber · lore

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

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.
Show 30 quoted lines
> 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

Avery Pennarun· Sep 4, 2008, 02:04 UTC · re: Boyd Lynn Gerber · lore

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

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
Boyd Lynn Gerber· Sep 4, 2008, 02:38 UTC · re: Avery Pennarun · lore

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

On Wed, 3 Sep 2008, Avery Pennarun wrote:
Show 8 quoted lines
> 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.

Show 6 quoted lines
> 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

Junio C Hamano· Sep 4, 2008, 03:33 UTC · re: Boyd Lynn Gerber · lore

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

Boyd Lynn Gerber <gerberb@zenez.com> writes:
Show 16 quoted lines
> 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");
Boyd Lynn Gerber· Sep 4, 2008, 03:58 UTC · re: Junio C Hamano · lore

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

On Wed, 3 Sep 2008, Junio C Hamano wrote:
Show 20 quoted lines
> 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

Junio C Hamano· Sep 4, 2008, 04:25 UTC · re: Boyd Lynn Gerber · lore

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

Boyd Lynn Gerber <gerberb@zenez.com> writes:
Show 8 quoted lines
> 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?

Boyd Lynn Gerber· Sep 4, 2008, 05:29 UTC · re: Junio C Hamano · lore

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

On Wed, 3 Sep 2008, Junio C Hamano wrote:
Show 21 quoted lines
> 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

Boyd Lynn Gerber· Sep 4, 2008, 05:39 UTC · re: Boyd Lynn Gerber · lore

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

On Wed, 3 Sep 2008, Boyd Lynn Gerber wrote:
Show 25 quoted lines
> 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
...
Show 38 quoted lines
> *   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

← back to recent threads