Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and apu-1.6
(HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm not exactly
sure where these are coming from for macOS
% uname -a
Darwin jimsys.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53
PST
FWIW, I have apr-1.6 here and cannot confirm the below. When compiling w/
httpd, DARWIN_10 is defined as required.
> On Mar 3, 2019, at 9:26 AM, wuzhouhui wrote:
>
> Hi,
>
> I found a compile warning in APR, following is a C program that will
> report warning when compiled in my system:
>
>
To take this discussion all the way back to APR project's potential
concerns...
On Wed, Mar 13, 2019 at 8:03 AM Jim Jagielski wrote:
>
> > On Mar 13, 2019, at 8:56 AM, Nick Kew wrote:
> >
> >> On 13 Mar 2019, at 12:43, Jim Jagielski wrote:
> >>
> >> Is there anyone else building 2.4 on macOS
Testing the theory now.
On first successful invocation/creation of libtool the answer is present,
the eval is not needed at all.
Subsequent ./configure invocation, same deal. In a typical linux this seems
to have been a noop.
I know I've seen the problem on aix or hpux or a similarly odd
On Wed, Mar 13, 2019 at 11:58 AM Yann Ylavic wrote:
> On Wed, Mar 13, 2019 at 5:20 PM William A Rowe Jr
> wrote:
> >
> > I think this comes from;
> >
> > AC_LIBTOOL_WIN32_DLL
> > AC_PROG_LIBTOOL
> > # get libtool's setting of shlibpath_var
> > eval `grep
On Wed, Mar 13, 2019 at 6:10 PM William A Rowe Jr wrote:
>
> On Wed, Mar 13, 2019 at 11:58 AM Yann Ylavic wrote:
>
> > The grep-ed double square brackets look weird to me, does not work
> > with my (ba)sh at least, so doesn't it enter the
> > REPLACE_WITH_YOUR_SHLIBPATH_VAR path anytime?
>
> I
On Wed, Mar 13, 2019 at 5:20 PM William A Rowe Jr wrote:
>
> I think this comes from;
>
> AC_LIBTOOL_WIN32_DLL
> AC_PROG_LIBTOOL
> # get libtool's setting of shlibpath_var
> eval `grep "^shlibpath_var=[[A-Z_]]*$" $apr_builddir/libtool`
> if test "x$shlibpath_var" = "x";
I think this comes from;
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL
# get libtool's setting of shlibpath_var
eval `grep "^shlibpath_var=[[A-Z_]]*$" $apr_builddir/libtool`
if test "x$shlibpath_var" = "x"; then
shlibpath_var=REPLACE_WITH_YOUR_SHLIBPATH_VAR
fi
First pass;
rm: cannot remove 'conftest*': No such file or directory
rm: cannot remove 'conftest*': No such file or directory
grep: /home/wrowe/dev/build/apr2-ossl111/libtool: No such file or directory
We cause that last step in configure.in of apr. During a first ./configure
in a vpath build,
On Tue, Mar 12, 2019 at 02:21:46PM -0500, William A Rowe Jr wrote:
> Rereading the APR_CHECK_TYPES_COMPATIBLE logic, I misread it. We test and
> successively pass ssize_t as int compatible, followed by retesting and
> passing ssize_t as long compatible, so the resulting
> APR_SSIZE_T_FMT pattern
On Wed, Mar 13, 2019 at 11:47 AM Yann Ylavic wrote:
>
> On Fri, Mar 8, 2019 at 9:19 PM William A Rowe Jr wrote:
> >
> > On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr
> > wrote:
> >>
> >> Do we want to do something about de-prioritizing sysv semaphores
> >> on linux by default with the
On Fri, Mar 8, 2019 at 9:19 PM William A Rowe Jr wrote:
>
> On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr wrote:
>>
>> Do we want to do something about de-prioritizing sysv semaphores
>> on linux by default with the 1.7.0 release?
>
> Comments? I know some distributors already hack around
12 matches
Mail list logo
