All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: dev <dev@cor0.com>
Cc: jrnieder@gmail.com, git@vger.kernel.org
Subject: Re: problem with def of inet_ntop() in git-compat-util.h as well as other places
Date: Wed, 27 Aug 2014 16:06:12 -0400	[thread overview]
Message-ID: <20140827200612.GA10469@peff.net> (raw)
In-Reply-To: <805178325.32077.1409168920760.JavaMail.vpopmail@webmail2.networksolutionsemail.com>

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

  reply	other threads:[~2014-08-27 20:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 19:15 problem with def of inet_ntop() in git-compat-util.h as well as other places dev
2014-08-27 19:28 ` Jeff King
2014-08-27 19:48   ` dev
2014-08-27 20:06     ` Jeff King [this message]
2014-08-27 21:00       ` dev
2014-08-27 22:28         ` Jonathan Nieder
2014-08-28  4:54           ` dev
2014-08-29  0:05             ` brian m. carlson
2014-08-30 15:25               ` dev
2014-08-28  6:51           ` dev
2014-08-27 19:31 ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140827200612.GA10469@peff.net \
    --to=peff@peff.net \
    --cc=dev@cor0.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.