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



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

  reply	other threads:[~2014-08-27 21:00 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
2014-08-27 21:00       ` dev [this message]
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=597210348.36175.1409173228026.JavaMail.vpopmail@webmail2.networksolutionsemail.com \
    --to=dev@cor0.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /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.