Here is a new adaption of gen-build.py, including the config
files.
Enjoy!
- Sascha
gen-build.sh
Description: Bourne shell script
passwd
strings
tables
include/
atomic
dso
file_io
locks
memory
misc
mmap
network_io
poll
random
shmem
support
threadproc
time
user
Should I assume that this is broken on the same platforms where
gen-build.py is broken (where a mix of unix and system-specific
code is used)?
The shell script uses similar logic, so I am afraid it might
have similar issues as well. I suppose you refer to this
rule deciding which
A shell script generating build-exports.mk is attached.
The implementation lacks cyclic reference detection (some
header files point to each other). This can be resolved by
splitting the 2-3 header files though.
- Sascha
gen-build.sh
Description: Bourne shell script
Please get your facts straight.
httpd is still just as buildable on such platforms regardless of
gen-build.py: from the release tarballs. Building from a CVS checkout
cannot be done without extra tools, but that has always been true in
2.0: you need libtool and autoconf (not to
autoconf does not use perl.
It has done since 2.50 AFAIK: from the README in 2.59:
Fortunately, one can choose not to use the horrible autoconf
2.5x. The sane versions up to 2.13 don't require perl for
buildconf'ing APR or httpd.
- Sascha
On Fri, 20 Feb 2004, Patrick Welche wrote:
On Fri, Feb 20, 2004 at 11:23:02AM +0100, Sascha Schumann wrote:
A shell script generating build-exports.mk is attached.
The implementation lacks cyclic reference detection (some
header files point to each other). This can
requiring automake is not something I personally would be excited about...
I'd
like to see how bad a conversion to ordinary sh would turn out.. also, I'd
guess that a conversion to the less cool but more widely
ported/precompiled/preinstalled P* scripting language would be a rather quick
The subject is whether Python can be required for running buildconf, not
for running configure make. I don't see a problem requiring Python
for buildconf.
The problem with python is that it is an exotic language and
hardly installed anywhere (not everyone runs Linux). Just
As part of the configure process, I would agree with you, but as part of
buildconf, I disagree--not everyone needs to run buildconf--only
developers, and if you're a developer, it's *really* not asking that
much to have Python on your dev box.
That must be a wonderful world where you run
This is definitely more readable, and seems to work fine here, good to
see someone looked into this problem. Nobody else has cared about
fixing the IRIX build for months (there's a PR on this) so I'd say go
ahead and commit this. I think you're missing a semi-colon on the {
print ... }
Hi there,
the sed on IRIX does not cooperate with the complex sed
expressions used to cut out and transform the proper layout
section. Thus configure has been failing since 2.0.40 or
so on IRIX.
Therefore I propose a simpler solution in the form of a 3
line awk
On Sun, 23 Mar 2003, Cliff Woolley wrote:
On Sun, 23 Mar 2003, Craig Rodrigues wrote:
But it exists in the APR codebase,
I don't count that as making it necessarily correct. :) But even if it
is correct on Netware, that doesn't make it correct on FreeBSD. And I'm
pretty sure it's not.
Here is a small proof of concept which
- detects whether sendfile(64) are available on the platform
at run-time
- uses sendfile up to its maximum, if sendfile64 does not
exist
The attached a.out was built from ap_sendfile.c on a
x86/glibc-2.2 box.
strace with
My previous thought was to do a platform-specific disabling of large
files on Linux (perhaps enabling it where there is a good version of
glibc). But, no one ever responded to that idea. I think it makes
the most sense, but I don't know.
It's actually quite simple from my POV and you
apr_snprintf(p, NULL, 0, %s BAR, FOO);
currently returns 0, after the changes, it would return 7.
8, surely?
sn?printf exclude the NUL byte in the counting process, hence
it is 7 (3+3+1).
- Sascha
Hummm. I was thinking we would create an entirely new set of APR calls
to encapsulate an event drivent network i/o interface (/dev/poll,
KQEnqueue/KQDequeue, IOCompletion ports, etc.). I'll try to work up an API
this week.
Here are some resources which you might consider during the
If 'errno' is a function call, how the heck does 'errno = 0;' do
anything? If it works because the compiler/system treats errno
as a integral value, then everything else is moot.
int *func_call();
#define errno *func_call()
I don't see the problem with return errno; though.
-
Exactly... we're still back to integral values. Of course, returning
a *int and an int are different (and therefore the above can't be a
full implemetation), but the concept still implies that we're integral.
Actually, that is conceptually the full interface definition.
The function
Just an addendum to the issue Cliff encountered with PHP.
This was traced down to a minor abnormality in autoconf-2.50
which apparently was eliminated in later versions. I've
committed a workaround for that. Case closed.
- Sascha
On Wed, 15 May 2002, Joe Orton wrote:
Any problems with these patches or could they be applied?
I've reviewed and committed those patches. Thanks!
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
From IRC, I already have a +1 from Justin and Sander. So I'd say we have
enough positive traction for the move. But does anybody see any *problems*
or have a reason to *not* require 1.4 ?
PHP has required 1.4.x for months and our latest distributions
are based on it; no problems so
On Tue, 14 May 2002, Aaron Bannert wrote:
On Tue, May 14, 2002 at 12:44:33AM -0700, Greg Stein wrote:
libtool 1.3 has problems with intra-library dependencies. This is making
some of the dependency stuff in apr(-util) a bit more complicated than it
needs to be.
The simple answer is to
PHP seems to require a magic combination of versions for libtool,
autoconf, and automake that allow it to build properly, and can on
occasion freak out if you don't have the right combo (Cliff, what is
up with your slackware?).
Most likely a broken vendor installation of at least one
main/internal_functions.c was never generated. Now at least it would get
built by the Makefile if it *did* exist, which is more than used to
happen.
Do you see a line creating main/internal_functions.c when
running configure?
If yes, please send me the output of configure, after
The operating system pre-allocates those fd's (0..2 for Unix) -- why would
opening an SDBM ever return any of those file descriptors? The only way
would be if the consumer closed those handles beforehand. If the user
does something like that, their program is broken -- we shouldn't try
to
As I described, it would be possible for a user to close those
descriptors before doing something like say, opening an SDBM. If
they then try to _write_ to those (via something like write() to
stderr), then that is a programming error which we should not be
trying to solve.
Not
If a user knows that a third-party library (Oracle, whatever) can
provide messages to stderr, and they knowingly close that file
descriptor without dup()ing it elsewhere, then that is a bug in
their software.
Note that the author of the non-apr application does not
necessarily must
This is a complete Catch-22. The question is what to do about it.
I have some ideas, but I'd like to hear what other people think.
I'll outline what PHP is doing quite successfully in this
area. The described method allows you to build native
objects as well as libtool objects
On Thu, 18 Oct 2001, Pier Fumagalli wrote:
I was wondering, if I generate libtool via buildconf on a named machine
(let's say, Solaris), is that libtool portable to another platform (let's
say Linux)
Of course it is. :-)
- Sascha Experience
Btw, do we have any string matching code in apr or apr-util? I
can see the applicability of decent string matchers in other parts
than mod_include.
Note that BNDM inherits the limit of shift-and/or algos --
they only work well for patterns which are not longer than
the number of
Well, as the overly long title suggests, is there any reason that
malloc() is used in dso.c (unix and aix)? apr_palloc() seems
fine for these purposes (temporary string). Also, as a side
note, sizeof(char) is used in the allocation, which is extreaneous,
because a char
Wouldn't this would require EVERY single APR developer to upgrade
to autoconf 2.50? Yuck. -- justin
Additionally to that, using autoconf 2.50 is not encouraged
as it still produces unportable shell code in some cases.
For details, refer to the mailing list archive of new-httpd.
On Fri, 27 Apr 2001, Ian Holsman wrote:
Solaris 2.6 does not have a 'isinf' function
There are various ways:
Linux, BSD: isinf(a)
C99: (a) == INFINITY
Solaris: (fpclass(a) == FP_PINF) || (fpclass(a) == FP_NINF)
- Sascha
On Wed, 14 Feb 2001, Sander Striker wrote:
Hi,
We're looking for volunteers that will help us implement
a wrapper around APR to make it look like POSIX 1003.4a
(POSIX draft 4) threads.
We need this to serve an existing 8 million line project.
Instead of going through all the sources, we
On 7 Feb 2001, Jeff Trawick wrote:
Jeff Trawick [EMAIL PROTECTED] writes:
Roy T. Fielding [EMAIL PROTECTED] writes:
. we *know* that versions of glibc 2.2 have const char **
instead of char ** so make that work without any hints.m4
stuff (which would have to look at the
Btw, here is the reasoning for the change:
http://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-group-lid=270
That's a real PITA. How exactly are we supposed to handle platforms
this? Linux is getting warnings right now, which I dislike.
Why is it a PITA?
[Note: My connectivity is quite limited currently.. ]
Somewhat... but it does mean that we'd be looking down into .libs for the
libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that
one... (reaching into .libs is the basic question: do we or don't we?)
Am I correct
Hi,
am I right in assuming that there were no efforts so far to
make apr-util work with an APR which was not build in its
source directory (i.e. an httpd 2.0 build in a separate dir)?
- Sascha
Unless GCC defines __GLIBC__ (which it should not do), I
don't see any way how this expression can evaluate to false.
GCC doesn't define __GLIBC__, glibc header files do
Don't worry, that was a sort-of rhetorical statement. =)
I expected the AC_EGREP_HEADER macro to do
On 5 Jan 2001 [EMAIL PROTECTED] wrote:
rbb 01/01/05 09:19:57
Modified:.configure.in
Log:
Some Linux's do not define TCP_CORK.
I guess you are referring to libc 5.x.x systems? There are
still kernels around (2.0.x, early 2.2.x possibly) which
don't
On Fri, 5 Jan 2001 [EMAIL PROTECTED] wrote:
Some Linux's do not define TCP_CORK.
I guess you are referring to libc 5.x.x systems? There are
still kernels around (2.0.x, early 2.2.x possibly) which
don't support TCP_CORK, so I think we should not simply
presume
It's false on Mandrake 7.1 too. I am in the middle of testing a patch
that just looks for sendfile. I think that is the safest way to code
this.
Yeah, instead of curing the problem the Right Way, we just
work around it by relying on well-established assumptions.
Great solution.
On Thu, 4 Jan 2001, Greg Stein wrote:
[ david misfired, and this went straight to me; bringing back to the list ]
Sascha said this wasn't needed on BSDs, but David says yes.
What I said was this:
All BSDs, **except** BSD/OS.
Remember that thread in late September?
Somebody
Sascha is being obtuse, when he should have simply said what he meant. That
would have kept the discussion much cleaner (shame on you, Sascha).
If I say X does not work in context Y, it does not
translate to I don't like X.
What is so unclear in that sentence? Were people
I had too much free time today, so I created make_export.awk.
During that I noticed that I either lack some awk knowledge
or that the awk's expression mechanism lacks a useful feature
(backreferencing). I've worked around that by using two sub's
in the respective block.
I dislike this idea. I realize (now) that awk is available on Windows,
but Perl is already required to build Apache on Windows, and all of a
sudden we are going to add the requirement of awk too. Why? We already
require Perl on every platform when building Apache, but we do not
currently
When I originally wrote the buildexports stuff, we didn't require Perl to
build Apache, because that file could be generated once and just bundled
with Apache. With the move to create those files during the build steps,
we now require Perl just to build. I think the best solution is to move
I would love to know what it is. The regex isn't that complex, and
regex's in Perl shouldn't have really changed between 5.005_02 and
5.005_03. Hm
I can repeat the same effect on another machine with Red Hat
5.1 (also 5.005_02).
Are we going to raise the entry barrier for
What makes you think the awk solution is any more portable than the Perl
solution? I would much rather determine what is happening than to just
give up on the Perl solution. Please take a look at the definition of
those functions and make sure they actually match the regex. You could
try
Hmm. Have you noticed apr_MD5Encode and apr_get_home_directory are in there
twice? Is it possible that you're getting doubles? Maybe you have a backup
copy of apr_uuid.h and apr_md5.h in your include directory, and it's picking
them up?
line was not cleared correctly. Whoops. I used the
We should document that URL for fetching a Windows-compatible AWK. Are there
binary distributions? I'd also be fine redistributing from apache.org so
that people don't have to hunt this stuff down at other sites.
Three candidates (create exactly the same output):
gawk 3.0.6 for Win32:
Ok, so you don't like automake and gnu make.
May I gently request that you read this article:
http://www.perl.com/pub/2000/12/advocacy.html?wwwrrr_20001213.txt
If I say X does not work in context Y, it does not
translate to I don't like X.
This is an open source
On Wed, 13 Dec 2000, Greg Stein wrote:
*) Subversion uses autogen.sh
*) APR and Apache uses buildconf
*) APRUTIL uses buildconf.sh (I stayed with the buildconf name, but felt
that adding the .sh was much more declarative about what is going on)
I'm +1 on changing APR and Apache to
Besides, as I said: the .sh extension is more for the user to know oh, this
is a shell script that I can run. Those other scripts you mention are all
internal so who cares how they're named? Heck, let's call them script1,
script2, and script3. :-)
May I answer this with a quote of the
On Tue, 5 Dec 2000 [EMAIL PROTECTED] wrote:
Modified:.Makefile.in
Log:
aprutil in the distribution form does not want to remove configure or
aprutils.exports (these two files are part of the distribution and users
cannot typically regenerate them). But the
For all the libtool illiterates :-)) out there, you might
want to consider reading autobook, a free book featuring two
chapters about libtool. The first one is directly applicable
to Apache and APR:
http://sources.redhat.com/autobook/
TOC:
That's both :pserver: and :ext: via ssh, to both apache.org and
locus.apache.org (and I can ssh to locus and have set up my ssh
authorization there).
You probably want to use SSH for APR since that will allow you to make
changes. The command would look like:
cvs -d :ext:[EMAIL
57 matches
Mail list logo
