(Hopefully this is the right list... :-))
While trying to build gawk on Tandem NSK/OSS, I ran into dlopen, dlsys
and dlerror being unresolved. I finally determined that these are
present in the 'zrldsrl' library.
I have written to bug-gawk (AT gnu.org), but thought it would be nice if
autoco
Howard Chu wrote:
Paul Eggert wrote:
"Ilya N. Golubev" <[EMAIL PROTECTED]> writes:
Have no systems with broken `return' at hand,
That's the fundamental problem. These systems are _ancient_ -- they
all predate C89 -- and they are so old that nobody uses them any more.
As I recall when porti
Paul Eggert wrote:
Matthew Woehlke wrote:
Hmm, mainframes? I want to say VMS also uses 'return 1' for success
(or maybe it even needs exit; I'm not the one that has to deal with
our VMS systems).
As I understand it, on VMS, exit(N) is equivalent to main returning N;
it's
Ralf Wildenhues wrote:
* Matthew Woehlke wrote on Tue, Nov 07, 2006 at 09:54:57PM CET:
(Hopefully this is the right list... :-))
No, it's not, but it's good you mention it. Libtool would need a
similar change.
Right. I think it's best, then, to let this thread die. There are
Thomas Dickey wrote:
On Mon, 13 Nov 2006, Paul Eggert wrote:
If they conform to C89 there should be no problem. In C89, returning
N from 'main' is like 'exit(N)'. This thread is about pre-C89 systems
where the return value from 'main' is mangled.
For example (reading the comments that you ma
Ralf Wildenhues wrote:
* Peter O'Gorman wrote on Tue, Dec 12, 2006 at 01:26:42PM CET:
There is a test to check the stack direction when building the
replacement alloca. This test returns bad results with optimizations:
[...]
exit (find_stack_direction () < 0);
It also fails with -xO2 on HPU
Paul Eggert wrote:
What about invoking the function indirectly, i.e. declare a pointer to
the function, set it to the function, and call
Sorry, none of that stuff is guaranteed to work with ISO C.
The implementation is allowed to dump core if you compare
A < B where A and B point to distin
Ralf Wildenhues wrote:
[snip]
There are several aspects to this issue:
[more snip]
- The distro maker may want to do
for pkg in *; do
cd pkg
./configure $common_options && make ...
cd ..
done
So even when we have a way to find out the set of allowed arguments
i
Bob Friesenhahn wrote:
On Thu, 14 Dec 2006, Matthew Woehlke wrote:
- As long as we don't have a way to find out the set of allowed
arguments in a package tree hierarchy, there needs to be a way to
turn off the warning for a developer. A new macro would do.
Should the macro be overri
Ralf Wildenhues wrote:
* Matthew Woehlke wrote on Thu, Dec 14, 2006 at 06:17:47PM CET:
Ralf Wildenhues wrote:
- When should the warning(s) be output?
I would say 'at the beginning', and make 'em good and noisy, so unless
the user hits 'enter' and looks away really f
Steven G. Johnson wrote:
How about:
--enable-option-checking (the default, produces a warning)
--enable-option-checking=fatal (produces error)
--disable-option-checking (disables warnings/errors)
AC_DISABLE_OPTION_CHECKING (makes "disable" the default)
Yes, if that does not chok
While compiling KDE 3.5.5 (from stable sources) on a almost-pristine(*)
FC6/Zod machine, I get a number of "Present But Cannot Be Compiled"
warnings. I am not sure what "the AC_PACKAGE_NAME lists" are; is this a
good place to report them (and is anyone interested)?
(* I had to build a few addi
Ralf Wildenhues wrote:
Matthew Woehlke wrote on Tue, Jan 09, 2007 at 09:11:21PM CET:
While compiling KDE 3.5.5 (from stable sources) on a almost-pristine(*)
FC6/Zod machine, I get a number of "Present But Cannot Be Compiled"
warnings.
config.log tells you details about the warnings
Ralf Wildenhues wrote:
Matthew Woehlke wrote on Tue, Jan 09, 2007 at 10:03:39PM CET:
Ralf Wildenhues wrote:
Oh. I think there was a bug in Autoconf 2.60 and earlier[...]
Hmm, ok so... I should report 'present but cannot be compiled' headers
to the package maintainers (i.e.
Ralf Wildenhues wrote:
I don't have autoconf > 2.59 on that box, but I am forwarding this to
> kde-devel to see if anyone else can help (and to let them know about the
> problem). Any autoconf folks that want to look could download any KDE
> 3.5.5 package to see an example of this problem (at l
(The autoconf side of this thread seems resolved, please drop them when
replying unless you have a reason not to.)
Ralf Wildenhues wrote:
* Matthew Woehlke wrote on Thu, Jan 11, 2007 at 01:01:09AM CET:
Actually, looking in e.g.
http://websvn.kde.org/branches/KDE/3.5/kdelibs/configure.in.in
(If this isn't the place for 'how do I...?' questions, please re-direct
me, but I do see it isn't the -bugs list.)
First off, I have a very skeleton configure.in (see below). How do I add
'--enable-debug' to this? (I see AC_ARG_ENABLE, but is there not a
standard one for debug? I can't find on
Braden McDaniel wrote:
Matthew Woehlke wrote:
(If this isn't the place for 'how do I...?' questions, please
re-direct me, but I do see it isn't the -bugs list.)
First off, I have a very skeleton configure.in (see below). How do I add
The name "configure.ac&q
Keith MARSHALL wrote:
With Cygwin, you are running a POSIX emulation layer on top of the Win32 OS,
so your app gets all of the initialisation support you'd expect from a true
POSIX system. There is no need for us to concern ourselves with the details
of how this happens; some very clever people
Keith MARSHALL wrote:
Matthew Woehlke wrote:
1) The environment that is passed to your app is again a *verbatim* copy of
that which was defined in the bash shell.
2) When you access command line arguments in argv, they are again *verbatim*
copies of what you typed on the command line
Brian Dessent wrote a really long description of what Cygwin does when
launching a Win32-native application:
Thanks for that!
[1] PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, TEMP
...so for the sake of my sanity, this is the list of variables that are
"translated" from POSIX-style to DOS-style
Keith MARSHALL wrote:
Brian Dessent wrote, quoting Bob Rossi:
If your app links against a POSIX emulation layer (cygwin1.dll or
msys-1.0.dll) then use colon, otherwise use semicolon. This is a static
condition that does not change at all once the app is built, i.e. it
does not depend on how it'
Ralf Wildenhues wrote:
My primary concern here is self defence against triggering those
semantics unintentionally while writing shell code bits like
sed -n /x/p
[snip]
Cygwin should never, ever do any translation of this. I believe Keith
was saying that it's MSYS you have to watch out for h
Andreas Schwab wrote:
Why does config.guess prints "unknown" instead of "pc" for PCs?
What is a PC anyway? Is a 32 cpu system a PC?
Given that I think most laymen wouldn't call a "Mac" a "PC", one answer
might be a computer with IBM-PC compatible hardware... i.e. anything x86
or x86_64 arc
Warren Young wrote:
Matthew Woehlke wrote:
Andreas Schwab wrote:
What is a PC anyway? Is a 32 cpu system a PC?
...anything x86 or x86_64 architecture.
So is this:
http://unisys.com/products/enterprise__servers/high_d_end__servers/features.htm
a PC, then?
If a "PC" is
Paul Eggert wrote:
Eric Blake writes:
I tried finding something in POSIX or C99 that said that an implementation
could provide long long without unsigned long long, but did not see
anything obvious
C99 requires both types. C89 requires neither, and Tandem provides just
one of them as an exten
Harald Servat wrote:
I'm trying to provide a compiler to this macro (using it's name and
the full path name) when some special conditions occur but as it isn't
on the default $PATH, AC_PROG_CC skips it.
Right now, I can only find two solutions. Just add the the directory
that contains this c
Harald Servat wrote:
Matthew Woehlke wrote:
Harald Servat wrote:
I'm trying to provide a compiler to this macro (using it's name and
the full path name) when some special conditions occur but as it isn't
on the default $PATH, AC_PROG_CC skips it.
Right now, I can only fin
28 matches
Mail list logo
