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
>
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
%% 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 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.
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:
>> 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?
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
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
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
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 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
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
> "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
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
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
--- 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
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
[ 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
[ 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
> > 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 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
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:
> 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!
> ] 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
"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
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 <
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 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
"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
| 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
> "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
| 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
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
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
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
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
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
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.
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
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
41 matches
Mail list logo
