Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
On August 28, 2014 at 8:05 PM "brian m. carlson" 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 tagvalue [0] NEEDED0x11ef7 libpcre.so.1 [1] NEEDED0x11f04 libz.so.1 [2] NEEDED0x11f0e libintl.so.8 [3] NEEDED0x11f1b libiconv.so.2 [4] NEEDED0x11e67 libsocket.so.1 [5] NEEDED0x11e91 libnsl.so.1 [6] NEEDED0x11f29 libresolv.so.2 [7] NEEDED0x11f38 libcrypto.so.1.0.0 [8] NEEDED0x11ead libpthread.so.1 [9] NEEDED0x11ecf 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 0x10178 [15] STRTAB0x100018b08 [16] STRSZ 0x1216d [17] SYMTAB0x16418 [18] SYMENT0x18 [19] CHECKSUM 0x2dce [20] VERNEED 0x10002ac78 [21] VERNEEDNUM0x4 [22] PLTRELSZ 0x1338 [23] PLTREL0x7 [24] JMPREL0x10002c6c0 [25] RELA 0x10002c630 [26] RELASZ0x13c8 [27] RELAENT 0x18 [28] DEBUG 0 [29] FLAGS 0 0 [30] FLAGS_1 0 0 [31] SUNW_STRPAD 0x200 [32] SUNW_LDMACH 0x2bEM_SPARCV9 [33] PLTGOT0x10053dc00 [34-44] NULL 0 cool. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
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 signature.asc Description: Digital signature
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
On August 27, 2014 at 6:28 PM Jonathan Nieder 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
On August 27, 2014 at 6:28 PM Jonathan Nieder
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)
libiconvlibgit.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_SOLARISei_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 fileversion
[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 tagva
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
On August 27, 2014 at 4:06 PM Jeff King 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) libiconvlibgit.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
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
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 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 checki
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
