problem with def of inet_ntop() in git-compat-util.h as well as other places

problem with def of inet_ntop() in git-compat-util.h as well as other places

[dev]

per :


  http://pubs.opengroup.org/onlinepubs/009695399/functions/inet_ntop.html


The last parameter is not unsigned long but socklen_t size.

This causes a problem on things like Solaris :

 * new build flags
    CC credential-store.o
"git-compat-util.h", line 516: error: identifier redeclared: inet_ntop
        current : function(int, pointer to const void, pointer to char,
unsigned long) returning pointer to const char
        previous: function(int, pointer to const void, pointer to char,
unsigned int) returning pointer to const char :
"/usr/include/arpa/inet.h", line 68
cc: acomp failed for credential-store.c
gmake: *** [credential-store.o] Error 2



Therefore I hacked around it with a #ifdef __SunOS_5_10 for the sake of
getting the build done.


However ran into a problem, again, with compat/inet_ntop.c which seems
to be not needed at all since inet_ntop() handles both IPv6 and IPv4
just fine.   Really I don't see why this file gets carted around so much
as it is even in the Apache svn codebase as well.

Not needed.

Therefore I commented out the inet_ntop() function entirely therein.

Also the Makefile's generated are all borked full of GCCism "CFLAGS = -g
-O2 -Wall"  which means very little on some OS wherein the gcc compiler
is not the default.  Love GCC. I bootstrap it all the time. However this
is Solaris and am using ORacle Studio 12.3 compilers and therefore the
CFLAGS in the Makefiles are just silly.  Lastly, the linkage to libintl
should look in /usr/local/lib if the LD_LIBRARY_PATH and other env vars
are setup correctly. However the Makefile's seem to miss this fact and
-lintl needs to be manually hacked into place.

Still doesn't "just build" yet.  Getting there :-\

dev

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[Jeff King]

On Wed, Aug 27, 2014 at 03:15:05PM -0400, dev wrote:

> This causes a problem on things like Solaris :
> 
>  * new build flags
>     CC credential-store.o
> "git-compat-util.h", line 516: error: identifier redeclared: inet_ntop
>         current : function(int, pointer to const void, pointer to char,
> unsigned long) returning pointer to const char
>         previous: function(int, pointer to const void, pointer to char,
> unsigned int) returning pointer to const char :
> "/usr/include/arpa/inet.h", line 68
> cc: acomp failed for credential-store.c
> gmake: *** [credential-store.o] Error 2

That declaration should only be used if you have NO_INET_NTOP defined by
the Makefile. That is not defined by default for Solaris. Have you
specified it yourself, or are you using the autoconf script? If the
latter, I suspect its test for inet_ntop needs to be fixed.

> However ran into a problem, again, with compat/inet_ntop.c which seems
> to be not needed at all since inet_ntop() handles both IPv6 and IPv4
> just fine.   Really I don't see why this file gets carted around so much
> as it is even in the Apache svn codebase as well.

Again, that should not be compiled at all unless you have NO_INET_NTOP
set. Fixing that should solve both of your problems.

> Also the Makefile's generated are all borked full of GCCism "CFLAGS = -g
> -O2 -Wall"  which means very little on some OS wherein the gcc compiler
> is not the default.

Yes, this is a potential portability problem we've discussed before, but
literally nobody has ever complained. I suspect it's a combination of
many compilers accepting those arguments (e.g., clang is fine with it)
and people on exotic compilers accepting that "make CFLAGS=" is a
reasonable starting point (you can also put "CFLAGS = " into your
config.mak if you do not want to remember to include it on each make
invocation).

> is Solaris and am using ORacle Studio 12.3 compilers and therefore the
> CFLAGS in the Makefiles are just silly.  Lastly, the linkage to libintl
> should look in /usr/local/lib if the LD_LIBRARY_PATH and other env vars
> are setup correctly. However the Makefile's seem to miss this fact and
> -lintl needs to be manually hacked into place.

I do not usually see Makefiles peeking at LD_LIBRARY_PATH, which is for
runtime resolution. Do you need to set LDFLAGS in your environment (or
in config.mak)?

-Peff

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[Jonathan Nieder]

Hi,

dev wrote:

>     CC credential-store.o
> "git-compat-util.h", line 516: error: identifier redeclared: inet_ntop
>	current : function(int, pointer to const void, pointer to char, unsigned long) returning pointer to const char
>	previous: function(int, pointer to const void, pointer to char, unsigned int) returning pointer to const char :
>	"/usr/include/arpa/inet.h", line 68

Why is NO_INET_NTOP set?  What commands are you using to build?  If
you are using autoconf, what does your config.mak.autogen say?

Puzzled,
Jonathan

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[dev]

Good day gentlemen. With coffee in hand I am taking a crack and getting
git to compile out of the sources neatly and therefore I have hit a
few bumps.  Inline comments below :

On August 27, 2014 at 3:28 PM Jeff King <peff@peff.net> wrote:
> On Wed, Aug 27, 2014 at 03:15:05PM -0400, dev wrote:
>
> > This causes a problem on things like Solaris :
> >
> >  * new build flags
> >     CC credential-store.o
> > "git-compat-util.h", line 516: error: identifier redeclared:
> > inet_ntop
> >         current : function(int, pointer to const void, pointer to
> > char,
> > unsigned long) returning pointer to const char
> >         previous: function(int, pointer to const void, pointer to
> > char,
> > unsigned int) returning pointer to const char :
> > "/usr/include/arpa/inet.h", line 68
> > cc: acomp failed for credential-store.c
> > gmake: *** [credential-store.o] Error 2
>
> That declaration should only be used if you have NO_INET_NTOP defined
> by
> the Makefile.

wow.

OKay, in that case there seems to be another problem which, as you say,
would fix a few things in one shot. So we have inet_ntop() in the basic
socket function libs in Solaris for sure so we should not see
NO_INET_NTOP
defined.  But we are.  :-\

> That is not defined by default for Solaris. Have you
> specified it yourself, or are you using the autoconf script? If the
> latter, I suspect its test for inet_ntop needs to be fixed.

I am going to extract the tarball once again and start fresh.


$ mdigest -a sha256 $SRC/git-2.0.4.tar.gz
dd9df02b7dcc75f9777c4f802c6b8562180385ddde4e3b8479e079f99cd1d1c9
 /usr/local/src/git-2.0.4.tar.gz

$ gzip -dc $SRC/git-2.0.4.tar.gz | tar -xf -
$ mv git-2.0.4 git-2.0.4_SunOS5.10_sparcv9.002
$
$ cd git-2.0.4_SunOS5.10_sparcv9.002
$
$ echo $CFLAGS
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64
-xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc
-g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-xtarget=ultraT2 -xcache=8/16/4:4096/64/16
$
$ env | sort | grep LD
BUILD=/usr/local/build
LD=/usr/ccs/bin/sparcv9/ld
LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib
LD_OPTIONS=-64 -Qy
-R/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib
-L/usr/local/lib/$ISALIST:/usr/local/ssl/lib$ISALIST:/usr/local/lib:/usr/local/ssl/lib
LD_RUN_PATH=/usr/local/lib:/usr/local/ssl/lib
OLDPWD=/usr/local/build




I ran configure like so :


$ ./configure --enable-pthreads --with-openssl --with-libpcre
--with-curl --with-expat --with-iconv=/usr/local
--with-editor=/usr/xpg4/bin/vi --with-shell=/usr/local/bin/bash
--with-perl=/usr/local/bin/perl --with-zlib=/usr/local
configure: Setting lib to 'lib' (the default)
configure: Will try -pthread then -lpthread to enable POSIX Threads
configure: CHECKS for site configuration
configure: Setting ICONVDIR to /usr/local
configure: Setting DEFAULT_EDITOR to /usr/xpg4/bin/vi
configure: Setting SHELL_PATH to /usr/local/bin/bash
configure: Setting PERL_PATH to /usr/local/bin/perl
configure: Setting ZLIB_PATH to /usr/local
configure: CHECKS for programs
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether /opt/solarisstudio12.3/bin/cc accepts -g... yes
checking for /opt/solarisstudio12.3/bin/cc option to accept ISO C89...
none needed
checking for inline... inline
checking if linker supports -R... yes
checking for gtar... no
checking for tar... tar
checking for gnudiff... no
checking for gdiff... gdiff
checking for asciidoc... no
configure: CHECKS for libraries
checking for SHA1_Init in -lcrypto... yes
checking for pcre_version in -lpcre... yes
checking for curl_global_init in -lcurl... yes
checking for XML_ParserCreate in -lexpat... yes
checking for iconv in -liconv... yes
checking for deflateBound in -lz... yes
checking for socket in -lc... no
checking for inet_ntop... no
checking for inet_ntop in -lresolv... no
checking for inet_pton... no
checking for inet_pton in -lresolv... no
checking for hstrerror... no
checking for hstrerror in -lresolv... yes
checking for basename in -lc... yes
checking for gettext in -lc... yes
checking how to run the C preprocessor... /opt/solarisstudio12.3/bin/cc
-E
checking for grep that handles long lines and -e... /usr/xpg4/bin/grep
checking for egrep... /usr/xpg4/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
configure: CHECKS for header files
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking for inttypes.h... (cached) yes
checking for old iconv()... yes
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for socklen_t... yes
checking for struct dirent.d_ino... yes
checking for struct dirent.d_type... no
checking for struct passwd.pw_gecos... yes
checking for struct sockaddr_storage... yes
checking for struct addrinfo... yes
checking for getaddrinfo... yes
checking for library containing getaddrinfo... none required
checking whether the platform regex can handle null bytes... no
checking whether system succeeds to read fopen'ed directory... no
checking whether snprintf() and/or vsnprintf() return bogus value... no
configure: CHECKS for library functions
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking paths.h usability... no
checking paths.h presence... no
checking for paths.h... no
checking libcharset.h usability... yes
checking libcharset.h presence... yes
checking for libcharset.h... yes
checking for strings.h... (cached) yes
checking for locale_charset in -liconv... yes
checking for strcasestr... no
checking for memmem... no
checking for strlcpy... yes
checking for library containing strlcpy... none required
checking for uintmax_t... yes
checking for strtoumax... yes
checking for library containing strtoumax... none required
checking for setenv... yes
checking for library containing setenv... none required
checking for unsetenv... yes
checking for library containing unsetenv... none required
checking for mkdtemp... yes
checking for library containing mkdtemp... none required
checking for mkstemps... no
checking for initgroups... yes
checking for library containing initgroups... none required
checking for POSIX Threads with ''... yes
configure: creating ./config.status
config.status: creating config.mak.autogen
config.status: executing config.mak.autogen commands
$

Then I see in some Makefile's :

$ find . -type f -name Makefile | xargs grep "^CFLAGS" | cut -f2 -d\:
CFLAGS = -g -O2 -Wall
CFLAGS = -g -O2 -Wall
CFLAGS = -g -O2 -Wall
CFLAGS = -g -O2 -Wall
CFLAGS = -O2 -Wall
$


So CFLAGS is ignored entirely.


Also in the Makefile at the top level I see :


ifdef NO_INET_NTOP
        LIB_OBJS += compat/inet_ntop.o
        BASIC_CFLAGS += -DNO_INET_NTOP
endif
ifdef NO_INET_PTON
        LIB_OBJS += compat/inet_pton.o
        BASIC_CFLAGS += -DNO_INET_PTON
endif


No reason for either of those to be defined, but I bet that you are
right
and they are ... and should not be.

> > Also the Makefile's generated are all borked full of GCCism "CFLAGS
> > = -g
> > -O2 -Wall"  which means very little on some OS wherein the gcc
> > compiler
> > is not the default.
>
> Yes, this is a potential portability problem we've discussed before,
> but
> literally nobody has ever complained.

* wave *

> I suspect it's a combination of
> many compilers accepting those arguments (e.g., clang is fine with it)
> and people on exotic compilers accepting that "make CFLAGS=" is a
> reasonable starting point (you can also put "CFLAGS = " into your
> config.mak if you do not want to remember to include it on each make
> invocation).

A config.mak file eh ?

I must look for that.

> > is Solaris and am using ORacle Studio 12.3 compilers and therefore
> > the
> > CFLAGS in the Makefiles are just silly.  Lastly, the linkage to
> > libintl
> > should look in /usr/local/lib if the LD_LIBRARY_PATH and other env
> > vars
> > are setup correctly. However the Makefile's seem to miss this fact
> > and
> > -lintl needs to be manually hacked into place.
>
> I do not usually see Makefiles peeking at LD_LIBRARY_PATH, which is
> for
> runtime resolution. Do you need to set LDFLAGS in your environment (or
> in config.mak)?


Yep, you're right of course. You can see I have no LDFLAGS defined.
Guess
I need that.

Anyways, thanks for the input. I would love to see this "just build" and
with a few more emails and some tinkering it should right?

dev

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[Jeff King]

On Wed, Aug 27, 2014 at 03:48:40PM -0400, dev wrote:

> $ gzip -dc $SRC/git-2.0.4.tar.gz | tar -xf -
> $ mv git-2.0.4 git-2.0.4_SunOS5.10_sparcv9.002
> $
> $ cd git-2.0.4_SunOS5.10_sparcv9.002
> $
> $ echo $CFLAGS
> -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64
> -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc
> -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
> -xtarget=ultraT2 -xcache=8/16/4:4096/64/16

Note that git's Makefile will not read CFLAGS from the environment (you
have to give it to make on the command-line, or put it in config.mak).
However, running "./configure" with that in the environment should put
the result into config.mak.autogen.

> $ env | sort | grep LD
> BUILD=/usr/local/build
> LD=/usr/ccs/bin/sparcv9/ld
> LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib
> LD_OPTIONS=-64 -Qy
> -R/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib
> -L/usr/local/lib/$ISALIST:/usr/local/ssl/lib$ISALIST:/usr/local/lib:/usr/local/ssl/lib

I have never seen LD_OPTIONS before. The usual variable for this is
LDFLAGS, and note that it is handled in the environment the same way as
CFLAGS above.

> checking for inet_ntop... no
> checking for inet_ntop in -lresolv... no

Well, that's likely the source of some of your problems. The config.log
can probably tell you more about why the check does not find inet_ntop.

> Then I see in some Makefile's :
> 
> $ find . -type f -name Makefile | xargs grep "^CFLAGS" | cut -f2 -d\:
> CFLAGS = -g -O2 -Wall
> CFLAGS = -g -O2 -Wall
> CFLAGS = -g -O2 -Wall
> CFLAGS = -g -O2 -Wall
> CFLAGS = -O2 -Wall
> $
> 
> So CFLAGS is ignored entirely.

No, it's not. The Makefiles are not generated by autoconf, because
autoconf is not required to build git (most of us do not use it at all).
Instead, the static Makefile includes config.mak.autogen, which is
generated by autoconf when you run "./configure" (and which overrides
the default in the Makefile). Try grepping for CFLAGS in that file.

> Also in the Makefile at the top level I see :
> 
> ifdef NO_INET_NTOP
>         LIB_OBJS += compat/inet_ntop.o
>         BASIC_CFLAGS += -DNO_INET_NTOP
> endif
> ifdef NO_INET_PTON
>         LIB_OBJS += compat/inet_pton.o
>         BASIC_CFLAGS += -DNO_INET_PTON
> endif
> 
> No reason for either of those to be defined, but I bet that you are
> right
> and they are ... and should not be.

I think they are defined by your config.mak.autogen, based on the output
you showed above.

> Anyways, thanks for the input. I would love to see this "just build" and
> with a few more emails and some tinkering it should right?

I do not see anything that drastic that needs changed. Building
_without_ running ./configure might even just work (it has sane defaults
for many operating systems), though you would need to pass along the
bits from your environment, like:

  make CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS"

You would potentially also need to turn off a few feature flags manually
(e.g., NO_EXPAT, NO_GETTEXT). There's a complete list at the top of the
Makefile. The configure script can usually figure these out for you, but
the static Makefile does not.

-Peff

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[dev]

On August 27, 2014 at 4:06 PM Jeff King <peff@peff.net> wrote:
> On Wed, Aug 27, 2014 at 03:48:40PM -0400, dev wrote:
>
> > $ gzip -dc $SRC/git-2.0.4.tar.gz | tar -xf -
> > $ mv git-2.0.4 git-2.0.4_SunOS5.10_sparcv9.002
> > $
> > $ cd git-2.0.4_SunOS5.10_sparcv9.002
> > $
> > $ echo $CFLAGS
> > -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64
> > -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee
> > -mc
> > -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf
> > -xunroll=1
> > -xtarget=ultraT2 -xcache=8/16/4:4096/64/16
>
> Note that git's Makefile will not read CFLAGS from the environment
> (you
> have to give it to make on the command-line, or put it in config.mak).
> However, running "./configure" with that in the environment should put
> the result into config.mak.autogen.


Well I have heard now a few times of this config.mak file and when I
extract the source tarball I see :

$ ls -lap config*
-rw-r--r--   1 dclarke  adbs       44502 Jul 30 22:10 config.c
-rw-r--r--   1 dclarke  adbs         540 Jul 30 22:10 config.mak.in
-rw-r--r--   1 dclarke  adbs       15447 Jul 30 22:10 config.mak.uname
-rwxr-x---   1 dclarke  adbs      217698 Jul 30 22:10 configure
-rw-r--r--   1 dclarke  adbs       32144 Jul 30 22:10 configure.ac


So I guess I have to create a config.mak file from somewhere.

>From the INSTALL file I see that most of these variables are in the
pre-written and supposedly ready to run Makefile.  OKay.  I think I
had better crack that open and see what I need to change in there.
Most likely CFLAGS and a way to locate OpenSSL libs etc but who knows.

> I have never seen LD_OPTIONS before. The usual variable for this is
> LDFLAGS, and note that it is handled in the environment the same way
> as
> CFLAGS above.

The problem is that this is not Linux and not GNU ld and therefore :

http://docs.oracle.com/cd/E19253-01/817-1984/6mhm7pl1l/index.html

So if I want to ensure that things like ELF headers contain the correct
stuff to locate libraries ( never ever use LD_LIBRARY_PATH as it is
the kiss of death ) then I need things like LD_OPTIONS and others.

So I will work through this from the Makefile provided and see if I
can get the CFLAGS that I want as well as other env vars.

> > So CFLAGS is ignored entirely.
>
> No, it's not. The Makefiles are not generated by autoconf, because
> autoconf is not required to build git (most of us do not use it at
> all).

I should try that on Solaris once to see what happens.  Make popcorn.
See below.

> Instead, the static Makefile includes config.mak.autogen, which is
> generated by autoconf when you run "./configure" (and which overrides
> the default in the Makefile). Try grepping for CFLAGS in that file.
>
> > Also in the Makefile at the top level I see :
> >
> > ifdef NO_INET_NTOP
> >         LIB_OBJS += compat/inet_ntop.o
> >         BASIC_CFLAGS += -DNO_INET_NTOP
> > endif
> > ifdef NO_INET_PTON
> >         LIB_OBJS += compat/inet_pton.o
> >         BASIC_CFLAGS += -DNO_INET_PTON
> > endif
> >
> > No reason for either of those to be defined, but I bet that you are
> > right
> > and they are ... and should not be.
>
> I think they are defined by your config.mak.autogen, based on the
> output
> you showed above.
>
> > Anyways, thanks for the input. I would love to see this "just build"
> > and
> > with a few more emails and some tinkering it should right?
>
> I do not see anything that drastic that needs changed. Building
> _without_ running ./configure might even just work (it has sane
> defaults
> for many operating systems),


$ make
make: Fatal error in reader: Makefile, line 345: Unexpected end of line
seen


Instant fail.

Let's try GNU make :

$ gmake
GIT_VERSION = 2.0.4
    * new build flags
    CC credential-store.o
cc: -W option with unknown program all
gmake: *** [credential-store.o] Error 1
$

More instant fail.

Let's keep trying ...

> though you would need to pass along the
> bits from your environment, like:
>
>   make CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS"

Sounds good ... let's see :

gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS"
.
.
.  good things seem to happen ...
.
    LINK git-credential-store
cc: Warning: Option -64 passed to ld, if ld is invoked, ignored
otherwise
cc: Warning: multiple use of -Q option, previous one discarded.
ld: warning: option -Q appears more than once, first setting taken
Undefined                       first referenced
 symbol                             in file
libiconv_close                      libgit.a(utf8.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
libiconv_open                       libgit.a(utf8.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
libiconv                            libgit.a(utf8.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
ld: fatal: symbol referencing errors. No output written to
git-credential-store
gmake: *** [git-credential-store] Error 2
$

So this is not Linux and so a pile of fiddling is required. Welcome to
the world of Oracle Solaris where nothing from the Linux world ever
"just works".  It looks like somewhere along the line the idea of
linking
with -liconv or perhaps -lintl was lost.  Not sure yet.

> You would potentially also need to turn off a few feature flags
> manually
> (e.g., NO_EXPAT, NO_GETTEXT). There's a complete list at the top of
> the
> Makefile. The configure script can usually figure these out for you,
> but
> the static Makefile does not.

For now I want to keep chugging along to see if I can get a default
no-hack
build and then go back and start over with things in the Makefile to see
if I can get the whole process to make the binaries that I want with
the required bits in the ELF headers and correctly NEEDed libs etc.

dev

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[Jonathan Nieder]

Hi again,

dev wrote:

> So I guess I have to create a config.mak file from somewhere.

Sorry, let's take a step back.

What exact commands do you use to build, starting from a pristine
extracted tarball?  What output do you get back?

[...]
> Undefined                       first referenced
>  symbol                             in file
> libiconv_close                      libgit.a(utf8.o)  (symbol belongs to implicit dependency /usr/local/lib/libiconv.so.2)

Sounds like NEEDS_LIBICONV should be set on Solaris.  You can test
this by passing NEEDS_LIBICONV=YesPlease on the gmake command line and
seeing what happens.

But it seems odd --- was iconv once part of libc on Solaris and then
moved out or something?  There have been lots of people building git
on Solaris over the years (and writing patches to fix other build
problems) without needing to set that flag.

[...]
>> You would potentially also need to turn off a few feature flags manually

The options for tweaking the build are described at the top of the
Makefile.

Thanks again,
Jonathan

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[dev]

On August 27, 2014 at 6:28 PM Jonathan Nieder <jrnieder@gmail.com>
wrote:
> Hi again,
>
> dev wrote:
>
> > So I guess I have to create a config.mak file from somewhere.
>
> Sorry, let's take a step back.
>
> What exact commands do you use to build, starting from a pristine
> extracted tarball?  What output do you get back?

$ ls $SRC/git*
/usr/local/src/git-2.0.4.tar.gz

$ gzip -dc /usr/local/src/git-2.0.4.tar.gz | tar -xf -
$ mv git-2.0.4 git-2.0.4_SunOS5.10_sparcv9.002
$ cd git-2.0.4_SunOS5.10_sparcv9.002

$ gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS"
    * new build flags
    CC credential-store.o
    * new link flags
    CC abspath.o
    CC advice.o
    CC alias.o
    CC alloc.o
    CC archive.o
    CC archive-tar.o
    CC archive-zip.o
    CC argv-array.o
    * new prefix flags
    CC attr.o
    CC base85.o
    CC bisect.o
    CC blob.o
    CC branch.o
    CC bulk-checkin.o
    CC bundle.o
    CC cache-tree.o
    CC color.o
    CC column.o
    CC combine-diff.o
    CC commit.o
    CC compat/obstack.o
. . .
    AR xdiff/lib.a
    LINK git-credential-store
cc: Warning: Option -64 passed to ld, if ld is invoked, ignored
otherwise
cc: Warning: multiple use of -Q option, previous one discarded.
ld: warning: option -Q appears more than once, first setting taken
Undefined                       first referenced
 symbol                             in file
libiconv_close                      libgit.a(utf8.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
libiconv_open                       libgit.a(utf8.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
libiconv                            libgit.a(utf8.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
ld: fatal: symbol referencing errors. No output written to
git-credential-store
gmake: *** [git-credential-store] Error 2
$

> Sounds like NEEDS_LIBICONV should be set on Solaris.  You can test
> this by passing NEEDS_LIBICONV=YesPlease on the gmake command line and
> seeing what happens.

That looks to be the ticket to a binary.

Entire build completes with piles of warnings but I get a git binary :

$ file git
git: ELF 64-bit MSB executable, SPARC V9, total store ordering, version
1, dynamically linked (uses shared libs), not stripped


$ ldd git
        libz.so.1 =>     /usr/local/lib/libz.so.1
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libintl.so.8 =>  /usr/local/lib/libintl.so.8
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libcrypto.so.1.0.0 =>    /usr/local/ssl/lib/libcrypto.so.1.0.0
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
        libscf.so.1 =>   /lib/64/libscf.so.1
        libdl.so.1 =>    /lib/64/libdl.so.1
        libz.so.1 (SUNW_1.1) =>  (version not found)
        libdoor.so.1 =>  /lib/64/libdoor.so.1
        libuutil.so.1 =>         /lib/64/libuutil.so.1
        libgen.so.1 =>   /lib/64/libgen.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1
        /platform/SUNW,T5240/lib/sparcv9/libmd_psr.so.1


Great, a problem with some libz.so.1 that we don't even need since we
have libz in /usr/local/lib just fine.  I have to look into that.

Otherwise :

$ ./git --version
git version 2.0.4


$ elfdump -devl git

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS64          ei_data:       ELFDATA2MSB
  ei_osabi:   ELFOSABI_SOLARIS    ei_abiversion: EAV_SUNW_CURRENT
  e_machine:  EM_SPARCV9          e_version:     EV_CURRENT
  e_type:     ET_EXEC
  e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
  e_entry:           0x10002d960  e_ehsize:     64  e_shstrndx:  31
  e_shoff:              0xe327d0  e_shentsize:  64  e_shnum:     32
  e_phoff:                  0x40  e_phentsize:  56  e_phnum:     5

Version Needed Section:  .SUNW_version
     index  file                        version
       [2]  libsocket.so.1              SUNW_1.4
       [3]                              SUNW_1.1             [ INFO ]
       [4]                              SUNW_0.7             [ INFO ]
       [5]  libnsl.so.1                 SUNW_0.7
       [6]                              SUNWprivate_1.1
       [7]  libpthread.so.1             SUNW_1.2
       [8]                              SUNW_0.9             [ INFO ]
       [9]  libc.so.1                   SUNW_1.22
      [10]                              SUNW_1.19            [ INFO ]
      [11]                              SUNW_1.18            [ INFO ]
      [12]                              SUNW_1.1             [ INFO ]
      [13]                              SUNW_0.9             [ INFO ]
      [14]                              SUNW_0.7             [ INFO ]
      [15]                              SUNWprivate_1.1

Dynamic Section:  .dynamic
     index  tag                value
       [0]  NEEDED            0x11ecb             libz.so.1
       [1]  NEEDED            0x11ed5             libiconv.so.2
       [2]  NEEDED            0x11ee3             libintl.so.8
       [3]  NEEDED            0x11e3b             libsocket.so.1
       [4]  NEEDED            0x11e65             libnsl.so.1
       [5]  NEEDED            0x11ef0             libcrypto.so.1.0.0
       [6]  NEEDED            0x11e81             libpthread.so.1
       [7]  NEEDED            0x11ea3             libc.so.1
       [8]  INIT              0x1003e2b88
       [9]  FINI              0x1003e2b98
      [10]  RUNPATH           0x11f03
            /usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/SALIST:/usr/local/ssl/lib/SALIST:/usr/local/lib:/usr/local/ssl/lib
      [11]  RPATH             0x11f03
            /usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/SALIST:/usr/local/ssl/lib/SALIST:/usr/local/lib:/usr/local/ssl/lib
      [12]  HASH              0x100000178
      [13]  STRTAB            0x100018a98
      [14]  STRSZ             0x121ab
      [15]  SYMTAB            0x100006408
      [16]  SYMENT            0x18
      [17]  CHECKSUM          0xaca0
      [18]  VERNEED           0x10002ac48
      [19]  VERNEEDNUM        0x4
      [20]  PLTRELSZ          0x12f0
      [21]  PLTREL            0x7
      [22]  JMPREL            0x10002c670
      [23]  RELA              0x10002c5f8
      [24]  RELASZ            0x1368
      [25]  RELAENT           0x18
      [26]  DEBUG             0
      [27]  FLAGS             0                   0
      [28]  FLAGS_1           0                   0
      [29]  SUNW_STRPAD       0x200
      [30]  SUNW_LDMACH       0x2b                EM_SPARCV9
      [31]  PLTGOT            0x10053d900
   [32-42]  NULL              0
$

Funny I don't see libcurl anywhere. Thought that was needed? Also the
RUNPATH
and RPATH look duplicated and slightly borked but the initial data there
is correct enough to locate all the libs except for some strange libz
issue.

What I need to do now is run some tests. Really I should keep going
to get linkage with libssh2 and libcurl as well as correct perl in
the /usr/local/bin directory. I'll have to keep tweaking with the
various magic on the "gmake" command I guess.

> But it seems odd --- was iconv once part of libc on Solaris and then
> moved out or something?

There are plenty of dependencies and therefore I have GNU libiconv thus
:

$ which iconv
/usr/local/bin/iconv

$ /usr/local/bin/iconv --version
iconv (GNU libiconv 1.14)
Copyright (C) 2000-2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.


$ ldd /usr/local/bin/iconv
        libintl.so.8 =>  /usr/local/lib/libintl.so.8
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libc.so.1 =>     /lib/64/libc.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1


> There have been lots of people building git
> on Solaris over the years (and writing patches to fix other build
> problems) without needing to set that flag.

Well I see what I see and am extracting from a tarball and reporting
precisely what is happening. Traditionally git has been a nightmare
to build on anything but linux. That is just my experience.  Let's
not even talk about OpenBSD.  A real nightmare.

dev

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[dev]

On August 27, 2014 at 6:28 PM Jonathan Nieder <jrnieder@gmail.com>
wrote:
> Hi again,
>
> dev wrote:
>
> > So I guess I have to create a config.mak file from somewhere.
>
> Sorry, let's take a step back.

Actually I think we have some real progress to report here.  After
scanning through the various magic incantations in the Makefile and
some trial and error I arrived at this gem :

$ date
Thu Aug 28 06:10:43 GMT 2014

$ ls $SRC/git*
/usr/local/src/git-2.0.4.tar.gz
$ gzip -dc /usr/local/src/git-2.0.4.tar.gz | tar -xf -
$ mv git-2.0.4 git-2.0.4_SunOS5.10_sparcv9.005
$ cd git-2.0.4_SunOS5.10_sparcv9.005

$ gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \
> SHELL_PATH=/usr/local/bin/bash \
> SANE_TOOL_PATH=/usr/local/bin \
> USE_LIBPCRE=1 LIBPCREDIR=/usr/local CURLDIR=/usr/local \
> EXPATDIR=/usr/local NEEDS_LIBINTL_BEFORE_LIBICONV=1 \
> NEEDS_SOCKET=1 NEEDS_RESOLV=1 USE_NSEC=1 \
> PERL_PATH=/usr/local/bin/perl \
> NO_PYTHON=1 DEFAULT_PAGER=/usr/xpg4/bin/more \
> DEFAULT_EDITOR=/usr/local/bin/vim DEFAULT_HELP_FORMAT=man \
> prefix=/usr/local
GIT_VERSION = 2.0.4
    * new build flags
    CC credential-store.o
    * new link flags
    CC abspath.o
    CC advice.o
    CC alias.o
.
.
.
    GEN bin-wrappers/test-wildmatch
    GEN git-remote-testgit
$

A full build.  Furthermore it looks like all the right bits are linked
in and a test clone from a few open source projects works well.

$ file git
git: ELF 64-bit MSB executable, SPARC V9, total store ordering, version
1, dynamically linked (uses shared libs), not stripped
$ ldd git
        libpcre.so.1 =>  /usr/local/lib/libpcre.so.1
        libz.so.1 =>     /usr/local/lib/libz.so.1
        libintl.so.8 =>  /usr/local/lib/libintl.so.8
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libresolv.so.2 =>        /lib/64/libresolv.so.2
        libcrypto.so.1.0.0 =>    /usr/local/ssl/lib/libcrypto.so.1.0.0
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
        libscf.so.1 =>   /lib/64/libscf.so.1
        libdl.so.1 =>    /lib/64/libdl.so.1
        libz.so.1 (SUNW_1.1) =>  (version not found)
        libdoor.so.1 =>  /lib/64/libdoor.so.1
        libuutil.so.1 =>         /lib/64/libuutil.so.1
        libgen.so.1 =>   /lib/64/libgen.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1
        /platform/SUNW,T5240/lib/sparcv9/libmd_psr.so.1
$

Ignore the misleading libz issue.  I really don't think it is a
problem however I may dig into it. That is libz.so.1 which is needed
by libcrypto.so.1.0.0 from OpenSSL 1.0.1i and I just don't see
an issue given that OpenSSL 1.0.1i passes all its tests.

I did run a few clone tests :

$ pwd
/export/home/dev/git_test
$ $BUILD/git-2.0.4_SunOS5.10_sparcv9.005/git clone --verbose
git://cmake.org/cmake.git
Cloning into 'cmake'...
warning: templates not found /usr/local/share/git-core/templates
remote: Counting objects: 162733, done.
remote: Compressing objects: 100% (41726/41726), done.
remote: Total 162733 (delta 124662), reused 157579 (delta 119831)
Receiving objects: 100% (162733/162733), 37.31 MiB | 1001.00 KiB/s,
done.
Resolving deltas: 100% (124662/124662), done.
Checking connectivity... done.
Checking out files: 100% (7410/7410), done.
$
$ cd cmake/
$ $BUILD/git-2.0.4_SunOS5.10_sparcv9.005/git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean
$ cd ..

$ $BUILD/git-2.0.4_SunOS5.10_sparcv9.005/git clone --verbose
git://git.apache.org/httpd.git
Cloning into 'httpd'...
warning: templates not found /usr/local/share/git-core/templates
remote: Counting objects: 391450, done.
remote: Compressing objects: 100% (80188/80188), done.
remote: Total 391450 (delta 331921), reused 367848 (delta 309308)
Receiving objects: 100% (391450/391450), 111.46 MiB | 420.00 KiB/s,
done.
Resolving deltas: 100% (331921/331921), done.
Checking connectivity... done.
Checking out files: 100% (3495/3495), done.


So that looks pretty good thus far.

I must say thank you for the guidance.  All I need to do now is figure
out a way to run a test over SSH with a dummy repo of some sort.

dev

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Thu, Aug 28, 2014 at 12:54:30AM -0400, dev wrote:
> Funny I don't see libcurl anywhere. Thought that was needed? Also the
> RUNPATH
> and RPATH look duplicated and slightly borked but the initial data there
> is correct enough to locate all the libs except for some strange libz
> issue.

The main git binary is not linked with libcurl, only the HTTP and FTP
programs.  You'd want to check git-remote-http, for instance.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: problem with def of inet_ntop() in git-compat-util.h as well as other places

[dev]

On August 28, 2014 at 8:05 PM "brian m. carlson"
<sandals@crustytoothpaste.net> wrote:
> On Thu, Aug 28, 2014 at 12:54:30AM -0400, dev wrote:
> > Funny I don't see libcurl anywhere. Thought that was needed? Also
> > the
> > RUNPATH
> > and RPATH look duplicated and slightly borked but the initial data
> > there
> > is correct enough to locate all the libs except for some strange
> > libz
> > issue.
>
> The main git binary is not linked with libcurl, only the HTTP and FTP
> programs.  You'd want to check git-remote-http, for instance.


wow ... you're right.  I had to go check to verify :

$ elfdump -d /usr/local/bin/git

Dynamic Section:  .dynamic
     index  tag                value
       [0]  NEEDED            0x11ef7             libpcre.so.1
       [1]  NEEDED            0x11f04             libz.so.1
       [2]  NEEDED            0x11f0e             libintl.so.8
       [3]  NEEDED            0x11f1b             libiconv.so.2
       [4]  NEEDED            0x11e67             libsocket.so.1
       [5]  NEEDED            0x11e91             libnsl.so.1
       [6]  NEEDED            0x11f29             libresolv.so.2
       [7]  NEEDED            0x11f38             libcrypto.so.1.0.0
       [8]  NEEDED            0x11ead             libpthread.so.1
       [9]  NEEDED            0x11ecf             libc.so.1
      [10]  INIT              0x1003e2f28
      [11]  FINI              0x1003e2f38
      [12]  RUNPATH           0x11f4b
            /usr/local/lib:/usr/local/ssl/lib
      [13]  RPATH             0x11f4b
            /usr/local/lib:/usr/local/ssl/lib
      [14]  HASH              0x100000178
      [15]  STRTAB            0x100018b08
      [16]  STRSZ             0x1216d
      [17]  SYMTAB            0x100006418
      [18]  SYMENT            0x18
      [19]  CHECKSUM          0x2dce
      [20]  VERNEED           0x10002ac78
      [21]  VERNEEDNUM        0x4
      [22]  PLTRELSZ          0x1338
      [23]  PLTREL            0x7
      [24]  JMPREL            0x10002c6c0
      [25]  RELA              0x10002c630
      [26]  RELASZ            0x13c8
      [27]  RELAENT           0x18
      [28]  DEBUG             0
      [29]  FLAGS             0                   0
      [30]  FLAGS_1           0                   0
      [31]  SUNW_STRPAD       0x200
      [32]  SUNW_LDMACH       0x2b                EM_SPARCV9
      [33]  PLTGOT            0x10053dc00
   [34-44]  NULL              0


cool.