Hello,
ad> I think the current Autoconf has solved these issues.
Hmm, I get the same problem with autoconf v2.13 and v2.14.
Is there a newer autoconf version than v2.14?
Where do I get it?
asysha2> autoconf --version
Autoconf version 2.13
asysha2> uname -a
SunOS asysha2 5.6 Generic_105181-22
Akim Demaille <[EMAIL PROTECTED]> writes:
> Meanwhile, I OK your patch.
Thanks. I've got an updated version attached below, with the only
additions that AC_OBJEXT is called before AC_EXEEXT in AC_PROG_CC,
AC_PROG_CXX and AC_PROG_F77 (AC_EXEEXT uses $ac_objext).
> I'd accept patches that do what
I'm OK with having as many --foodir as people might want (and
actually, I'd like to suggest that we recommend
./configure prefix=/usr
This is inconsistent with the normal command line option syntax.
We should stay with -- for consistency.
Anyway, making this option an install-time option is probably not a
good idea. Many programs will want to know, at compile-time, where
the configuration files are going to be installed. If they just take
sysconfdir from build time, they'd look for them in /usr/etc, instead
of
In some respect I see the current defaults, starting with `--prefix=\
/usr/local', as in some way supporting the *BSD systems since that's
more or less what their heir(7) manual page says.
It has nothing to do with *BSD in particular. People running GNU
programs on non-GNU systems ge
It's a common complaint that people can
./configure
make prefix=/foo
make install prefix=/foo
Why would anyone complain about this? Please explain
what you think is a problem.
People should *not* be allowed to do this (i.e., it should fail),
decisions should
On Sep 6, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> But this does not necessarily mean it ought to be a configure-time
> option. It could be a build-time option like prefix and sysconfdir.
Indeed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC
On Sep 6, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> It's a common complaint that people can
> ./configure
> make prefix=/foo
> make install prefix=/foo
> Why would anyone complain about this? Please explain
> what you think is a problem.
It's common to have pac
| I'm OK with having as many --foodir as people might want (and
| actually, I'd like to suggest that we recommend
|
| ./configure prefix=/usr
|
| This is inconsistent with the normal command line option syntax.
| We should stay with -- for consistency.
Yes, I agree. What I
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre explained very well something which concerns many of us.
It is hard to have this scheme work, and most packages have it wrong,
so basically you should just not rely on this (unless you are ready to
start again from scratc
> "Andreas" == Andreas Buschmann <[EMAIL PROTECTED]> writes:
Andreas> Hmm, I get the same problem with autoconf v2.13 and v2.14.
There is no such thing as 2.14.
Andreas> Is there a newer autoconf version than v2.14? Where do I get
Andreas> it?
ftp://alpha.gnu.org/gnu/autoconf/auto
| Thanks. I've got an updated version attached below, with the only
| additions that AC_OBJEXT is called before AC_EXEEXT in AC_PROG_CC,
| AC_PROG_CXX and AC_PROG_F77 (AC_EXEEXT uses $ac_objext).
Good!
| > I'd accept patches that do what you suggest too: have _AC_EXEEXT be
| > independent from
"Lars J. Aas" wrote:
> : Does anybody sees a means to compute this at compile time? Using the
> : same trick as we did for SIZEOF etc.
I did need a cross-compile AC_C_BIGENDIAN once upon a time, so there is a
AC_C_BIGENDIAN_CROSS submitted to the autoconf-archive (hopefully Peter
will update the
On Sep 6, 2000, Morten Eriksen <[EMAIL PROTECTED]> wrote:
> * acspecific.m4: _AC_OBJEXT was using AC_COMPILE_IFELSE, but
> AC_COMPILE_IFELSE depends on the value of $ac_objext. This
> dependency deadlock is broken by making _AC_OBJEXT independent
> of AC_COMPILE_I
On Wed, Sep 06, 2000 at 02:43:03PM +0200, Akim Demaille wrote:
: | > I'd accept patches that do what you suggest too: have _AC_EXEEXT be
: | > independent from AC_LINK_IFELSE, have AC_LINK|COMPILE_IFELSE require
: | > what they need, [...]
: |
: | I looked at the code, but the macros that does th
On Wed, Sep 06, 2000 at 02:32:18PM +0200, Guido Draheim wrote:
: will update the page some day). The basic idea is to create a binary
: from special C-source and "grep" the binary for some pattern. The C-source
[...]
:
: AC_MSG_CHECKING(whether byte order LOOKS bigendian)
: [
: cat >conftest.c <
"Lars J. Aas" <[EMAIL PROTECTED]> writes:
> Actually, it doesn't. Many of the initial configure tests fail on
> Cygwin because of this mess, I seem to recall.
None of the important ones, I believe (my patch fixes the only case I
could find).
There are some ugly hacks in Autoconf to take specia
Hello!
> ] if test -f conftest.c ; then
> if ${CC-cc} conftest.c -o conftest.o && test -f conftest.o ; then
> if test `grep -l BIGenDianSyS conftest.o` ; then
>echo $ac_n "looks big-endian ... " 1>&AC_FD_MSG
>ac_cv_c_bigendian=yes
> fi
> if t
On Sep 6, 2000, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> By the way, can anybody think of an algorithm that avoids explicit support
> for ASCII and EBCDIC only?
Instead of 0x4142, use (('A'<<8)|'B').
But then, if the encoding of the host platform is different from that
of the build platform,
Hello, Alexandre!
> Instead of 0x4142, use (('A'<<8)|'B').
Some compilers may disallow initializing arrays with such expressions.
> But then, if the encoding of the host platform is different from that
> of the build platform, the test would fail.
Really? I don't think such a compiler would pr
On Sep 6, 2000, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Really? I don't think such a compiler would produce working programs. If
> the compiler puts "Hello, World\n" in the encoding for the build platform
> into the object file the resulting executable will print garbage.
No, I'm talking abou
> > Really? I don't think such a compiler would produce working programs. If
> > the compiler puts "Hello, World\n" in the encoding for the build platform
> > into the object file the resulting executable will print garbage.
>
> No, I'm talking about the fact that the compiler would indeed output
[ On , September 6, 2000 at 14:19:23 (+0200), Akim Demaille wrote: ]
> Subject: Re: HTML format documentation
>
> > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> Alexandre> Of course, sometimes it's convenient to change these
> Alexandre> options at build time, but the potent
[ On Wednesday, September 6, 2000 at 05:07:18 (-0600), Richard Stallman wrote: ]
> Subject: Re: HTML format documentation
>
> In some respect I see the current defaults, starting with `--prefix=\
> /usr/local', as in some way supporting the *BSD systems since that's
> more or less what
Hello,
I am unable to run autoconf under Cygwin (1.1.4).
I get the message: NONE:0: /usr/bin/m4: Expecting line feed in frozen file
Is there any way to fix this problem ?
(I am not a subscriber of any mailing list, so please let me know if I need
to subscribe to a mailing list in order to get y
--- Emmanuel Blot <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am unable to run autoconf under Cygwin (1.1.4).
> I get the message: NONE:0: /usr/bin/m4: Expecting line feed in frozen file
>
> Is there any way to fix this problem ?
>
This is a \r\n (DOS line endings) vs \n (UNIX line endings) prob
Question:
I am building C++ shared libraries on various
non-GNU (and GNU of course) platforms so I need to
determine what compiler options to pass to generate
position independent code. Now I can always check
the compilers I have available and shell script
their options in, but is there a portab
Akim Demaille <[EMAIL PROTECTED]> writes:
> So it might be good to try to find an extensible scheme for directory
> specifications, something to parallel with --with and --enable.
> There are two ways to handle this: via `open options', just like
> --enable: we could recognize --foodir=FOO for a
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> I am building C++ shared libraries on various non-GNU (and GNU
Robert> of course) platforms so I need to determine what compiler
Robert> options to pass to generate position independent code.
Use libtool.
Robert> I'd also like
Libtool (by it's own admission) will not work for C++
shared libraries on most platforms. Here is a smattering
of what my OS's/Compilers we currently support without using
autoconf (i.e. it had better support these at least!)
These are comments I put in a Makefile.in to help me
determine what ha
Hi,
On Wed, Sep 06, 2000 at 03:48:30PM -0500, Robert Boehne wrote:
> Question:
>
> I am building C++ shared libraries on various
> non-GNU (and GNU of course) platforms so I need to
> determine what compiler options to pass to generate
> position independent code. Now I can always check
> the c
It's common to have packages that generate header files out of
configure options. If prefix changes from configure to build time,
the header files end up incorrect.
That would be a bug, according to the present spec.
Ok, so the right thing to do is to generate the header files a
Hi,
On Wed, Sep 06, 2000 at 05:28:01PM -0500, Robert Boehne wrote:
>
> Libtool (by it's own admission) will not work for C++
> shared libraries on most platforms.
Yes and no. The multi-language CVS branch addresses the bulk of the
problems.
> Here is a smattering
> of what my OS's/Compilers w
Pavel Roskin wrote:
>
> Hello!
>
> > ] if test -f conftest.c ; then
> > if ${CC-cc} conftest.c -o conftest.o && test -f conftest.o ; then
> > if test `grep -l BIGenDianSyS conftest.o` ; then
> >echo $ac_n "looks big-endian ... " 1>&AC_FD_MSG
> >ac_cv_c_bigend
To summarize: the code assumes host-platform to be 8-bit ebcdic
or 8-bit ascii. target-platform has 16-bit per short. This is the setup of
everyone who runs cross-compilers these days AFAIK. The test should explicitly
check that one answer has been found (neither zero nor two) and otherwise
fail
On Sep 6, 2000, Guido Draheim <[EMAIL PROTECTED]> wrote:
>> What happens if short integers occupy 4 bytes?
> Er, actually, I never heard of a platform where that is the case, anyway,
> both tests would fail and the test should choke. Can anybody point out
> a platfrom where sizeof(short) is 4?
On Sep 6, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> But then, what if someone
> starts a build with `prefix=/foo', modifies some files, then re-starts
> with `prefix=/bar'?
> Indeed, that would lead to bad results.
> I see the point you're making. If prefix were only a
On Sep 6, 2000, Guido Draheim <[EMAIL PROTECTED]> wrote:
> Now, would the code have a chance to go into main' autoconf anyway,
If you post a patch to autoconf-patches, I think it has a good chance
of making it to autoconf 2.51, if not 2.50.
--
Alexandre Oliva Enjoy Guarana', see http://www.
%% Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> * Is the advantage big enough to justify the incompatible change
>> of saying "You can't specify the prefix when you run Make"?
This should always be explicitly _allowed_ during "make install", as
long as "make" has been done first.
Either t
On Sep 7, 2000, "Paul D. Smith" <[EMAIL PROTECTED]> wrote:
> Either that, or DESTDIR should become a required feature of GNU
> installation.
> Actually, I kind of prefer the latter.
So do I.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
Paul D Smith <[EMAIL PROTECTED]> writes:
> %% Alexandre Oliva <[EMAIL PROTECTED]> writes:
>>> * Is the advantage big enough to justify the incompatible change
>>> of saying "You can't specify the prefix when you run Make"?
> This should always be explicitly _allowed_ during "make install", as
>
41 matches
Mail list logo
