[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lzip-bug] build issues - AIX and not gcc

From: Michael Felt
Subject: Re: [Lzip-bug] build issues - AIX and not gcc
Date: Sat, 11 Feb 2017 10:02:58 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

On 11-Feb-17 03:07, Antonio Diaz Diaz wrote:
Hello Michael,

Michael Felt wrote:
I know (i.e., just read) you are not a GNU project - so that explains
why the configure arguments are not working.
I stand corrected - "not working" should be "warns about". Many gnu projects silently ignore these "standard" arguments. And frankly, I do not know if one way is "better" than the other. Eye of the beholder.

In any case - you are quite correct that this is working.

AFAICT, the configure arguments are working as expected. It just warns about the options it does not recognize because it does not need them. See 'configure --help':

Usage: configure [options]

Options: [defaults in brackets]
  -h, --help            display this help and exit
  -V, --version         output version information and exit
  --srcdir=DIR          find the sources in DIR [. or ..]
  --prefix=DIR          install into DIR [/usr/local]
--exec-prefix=DIR base directory for arch-dependent files [$(prefix)]
  --bindir=DIR          user executables directory [$(exec_prefix)/bin]
  --datarootdir=DIR     base directory for doc and data [$(prefix)/share]
  --infodir=DIR         info files directory [$(datarootdir)/info]
  --mandir=DIR          man pages directory [$(datarootdir)/man]
  CXX=COMPILER          C++ compiler to use [g++]
  CPPFLAGS=OPTIONS      command line options for the preprocessor []
CXXFLAGS=OPTIONS command line options for the C++ compiler [-Wall -W -O2]
  LDFLAGS=OPTIONS       command line options for the linker []

However, assuming that CXX is c++ when g++ does not work - "is a bug".

Lzip's configure does not try to guess the name of the compiler. It leaves the user specify it as in '/configure CXX=xlc++'. Making configure guessing things is error prone and inefficient. Lzip can be configured, built and tested in less time than it takes for gzip's configure to run.
Actually, that only works if ${CXX} --version works. When it does not, CXX=c++ is assigned.

address@hidden:[/]xlc++ --version 2>/dev/null
address@hidden:[/]echo $?

And, more directly - it starts by always assuming CXX=g++ - even with CXX set to something else in the environment:

CXXFLAGS='-Wall -W -O2'

# checking whether we are using GNU C++.
if /bin/sh -c "${CXX} --version" > /dev/null 2>&1 ; then true
        CXXFLAGS='-W -O2'

And I cannot explain why gnu make is needed - except perhaps .cc might
not be recognixed as an automatic "source" for .o by POSIX make. (Not a
bug of yours - just something to be aware of).

I think that requiring GNU make is more or less standard for GNU packages because of the limitations in other makes.
Statisically, (from my packaging of 40 to 50 OSS packages - about 1 in 20 requires it, usually due to a Makefile syntax using ::

As the issue is that $< is not expanded to foo.cc I would assume that .cc is not in the "OEM" make RULES.

Just an FYI - errata - surprise people at a dinner party with your obscure makefile knowledge. In other words, just sharing about something that will only happen in a non GNU/Linux environment.

Best regards,

Lzip-bug mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]