You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Michael <ai...@felt.demon.nl> on 2017/12/03 21:09:32 UTC
Re: -q64 flag - gets in the way
On 17/11/2017 13:48, Michael Felt wrote:
>
>
> On 11/13/2017 7:46 AM, William A Rowe Jr wrote:
>> So, when we prepare source packages, we are using vendor or raw
>> autocruft packages... Depending on which release, this varies every
>> by a specific RM.
Well, I was hoping to be able to dual-build (i.e., 32 and 64-bit in one
package apr and apr-util - but it seems I'll have to package the
seperately) - lots of lines (sorry) - but there are differences in
include files that would make me uncomfortable to have a dual package
now. And, no real suggestion on how to make one. So, it seems keeping
the -q64 flag for 64-bit is a good idea (to prevent mixes) - and I'll
just manually add -q32 to my 32-bit package.
+++ start of diff output +++
michael@x071:[/data/prj/apache/apr/static/apr-1.6.3]diff -ru X32 X64
diff -ru X32/opt/bin/apr-1-config X64/opt/bin/apr-1-config
--- X32/opt/bin/apr-1-config 2017-11-30 18:19:56 +0000
+++ X64/opt/bin/apr-1-config 2017-11-30 18:16:21 +0000
@@ -33,7 +33,7 @@
CC="xlc_r"
CPP="xlc_r -E"
SHELL="/bin/sh"
-CPPFLAGS=" -U__STR__ -D_THREAD_SAFE -D_USE_IRS -D_LARGEFILE64_SOURCE"
+CPPFLAGS=" -U__STR__ -D_THREAD_SAFE -D_USE_IRS"
CFLAGS=" -qHALT=E"
LDFLAGS="-Wl,-brtl"
LIBS="-lpthread"
diff -ru X32/opt/build-1/apr_rules.mk X64/opt/build-1/apr_rules.mk
--- X32/opt/build-1/apr_rules.mk 2017-11-30 18:19:56 +0000
+++ X64/opt/build-1/apr_rules.mk 2017-11-30 18:16:21 +0000
@@ -41,7 +41,7 @@
# compilation and linking flags that are supposed to be set only by
the user.
# configure adds to them for tests, but we restore them at the end.
#
-CFLAGS=-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/buildaix/includes
+CFLAGS=-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64
-I/opt/buildaix/includes
CPPFLAGS=-I/opt/include -I/opt/buildaix/include
LDFLAGS=
LIBS=
@@ -51,7 +51,7 @@
# at the end of the process.
#
EXTRA_CFLAGS= -qHALT=E
-EXTRA_CPPFLAGS= -U__STR__ -D_THREAD_SAFE -D_USE_IRS -D_LARGEFILE64_SOURCE
+EXTRA_CPPFLAGS= -U__STR__ -D_THREAD_SAFE -D_USE_IRS
EXTRA_LDFLAGS=-Wl,-brtl
EXTRA_LIBS=-lpthread
EXTRA_INCLUDES=
diff -ru X32/opt/build-1/libtool X64/opt/build-1/libtool
--- X32/opt/build-1/libtool 2017-11-30 18:19:56 +0000
+++ X64/opt/build-1/libtool 2017-11-30 18:16:20 +0000
@@ -168,7 +168,7 @@
LTCC="xlc_r"
# LTCC compiler flags.
-LTCFLAGS="-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5
-I/opt/buildaix/includes"
+LTCFLAGS="-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64
-I/opt/buildaix/includes"
# Take the output of nm and produce a listing of raw symbols and C names.
global_symbol_pipe="sed -n -e 's/^.*[ ]\\([BCDT][BCDT]*\\)[ ][
]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p' | sed '/ __gnu_lto/d'"
diff -ru X32/opt/include/apr-1/apr.h X64/opt/include/apr-1/apr.h
--- X32/opt/include/apr-1/apr.h 2017-11-30 18:19:54 +0000
+++ X64/opt/include/apr-1/apr.h 2017-11-30 18:16:20 +0000
@@ -267,7 +267,7 @@
/* APR Feature Macros */
#define APR_HAS_SHARED_MEMORY 1
#define APR_HAS_THREADS 1
-#define APR_HAS_SENDFILE 1
+#define APR_HAS_SENDFILE 0
#define APR_HAS_MMAP 1
#define APR_HAS_FORK 1
#define APR_HAS_RANDOM 1
@@ -277,7 +277,7 @@
#define APR_HAS_UNICODE_FS 0
#define APR_HAS_PROC_INVOKED 0
#define APR_HAS_USER 1
-#define APR_HAS_LARGE_FILES 1
+#define APR_HAS_LARGE_FILES 0
#define APR_HAS_XTHREAD_FILES 0
#define APR_HAS_OS_UUID 0
@@ -315,7 +315,7 @@
typedef int apr_int32_t;
typedef unsigned int apr_uint32_t;
-#define APR_SIZEOF_VOIDP 4
+#define APR_SIZEOF_VOIDP 8
/*
* Darwin 10's default compiler (gcc42) builds for both 64 and
@@ -350,15 +350,15 @@
#define UINT64_C(v) (v ## ULL)
#endif
#else
- typedef long long apr_int64_t;
- typedef unsigned long long apr_uint64_t;
+ typedef long apr_int64_t;
+ typedef unsigned long apr_uint64_t;
#endif
typedef size_t apr_size_t;
typedef ssize_t apr_ssize_t;
-typedef off64_t apr_off_t;
+typedef off_t apr_off_t;
typedef socklen_t apr_socklen_t;
-typedef unsigned long apr_ino_t;
+typedef ino_t apr_ino_t;
#if APR_SIZEOF_VOIDP == 8
typedef apr_uint64_t apr_uintptr_t;
@@ -537,19 +537,19 @@
#define APR_SIZE_T_FMT "lu"
/* And APR_OFF_T_FMT */
-#define APR_OFF_T_FMT APR_INT64_T_FMT
+#define APR_OFF_T_FMT "ld"
/* And APR_PID_T_FMT */
#define APR_PID_T_FMT "d"
/* And APR_INT64_T_FMT */
-#define APR_INT64_T_FMT "lld"
+#define APR_INT64_T_FMT "ld"
/* And APR_UINT64_T_FMT */
-#define APR_UINT64_T_FMT "llu"
+#define APR_UINT64_T_FMT "lu"
/* And APR_UINT64_T_HEX_FMT */
-#define APR_UINT64_T_HEX_FMT "llx"
+#define APR_UINT64_T_HEX_FMT "lx"
/*
* Ensure we work with universal binaries on Darwin
diff -ru X32/opt/lib/apr.exp X64/opt/lib/apr.exp
--- X32/opt/lib/apr.exp 2017-11-30 18:19:56 +0000
+++ X64/opt/lib/apr.exp 2017-11-30 18:16:20 +0000
@@ -204,7 +204,6 @@
apr_socket_sendv
apr_socket_sendto
apr_socket_recvfrom
-apr_socket_sendfile
apr_socket_recv
apr_socket_opt_set
apr_socket_timeout_set
Binary files X32/opt/lib/libapr-1.a and X64/opt/lib/libapr-1.a differ
diff -ru X32/opt/lib/pkgconfig/apr-1.pc X64/opt/lib/pkgconfig/apr-1.pc
--- X32/opt/lib/pkgconfig/apr-1.pc 2017-11-30 18:19:56 +0000
+++ X64/opt/lib/pkgconfig/apr-1.pc 2017-11-30 18:16:20 +0000
@@ -8,4 +8,4 @@
Description: The Apache Portable Runtime library
Version: 1.6.3
Libs: -L${libdir} -lapr-${APR_MAJOR_VERSION} -lpthread
-Cflags: -U__STR__ -D_THREAD_SAFE -D_USE_IRS -D_LARGEFILE64_SOURCE
-qHALT=E -I${includedir}
+Cflags: -U__STR__ -D_THREAD_SAFE -D_USE_IRS -qHALT=E -I${includedir}
+++ END of diff output
>>
>> Q. 1) What source package are you talking about?
> http://apache.mirror.triple-it.nl//apr/apr-1.6.3.tar.bz2
>
> Building with:
> export OBJECT_MODE=64
> $ ../src/apr-1.6.3/configure --prefix=/opt --sysconfdir=/var/apr/etc
> --sharedstatedir=/var/apr/com --localstatedir=/var/apr
> --mandir=/usr/share/man --infodir=/opt/share/info/apr
>
> compiler: xlc
>
>>
>>
>> On Nov 12, 2017 11:47, "Michael" <aixtools@felt.demon.nl
>> <ma...@felt.demon.nl>> wrote:
>>
>> Hi.
>>
>> I try to package in dual-ABI (i.e., 32-bit and 64-bit modes) -
>> with binaries (and scripts) from the 64-bit side.
>> In other words, only the libraries are "dual".
>>
>> I just noticed that the build-1/libtool sets a dependancy to
>> 64-bit compiles.
>>
>> root@x064:[/data/prj/apache/apr-util-1.6.1]lslpp -w
>> /opt/build-1/libtool
>> File Fileset Type
>> ----------------------------------------------------------------------------
>> /opt/build-1/libtool
>> aixtools.apache.apr.rte File
>> root@x064:[/data/prj/apache/apr-util-1.6.1]grep q64
>> /opt/build-1/libtool
>> LTCFLAGS="-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64"
>>
>> I know how to 'fix it' in that I shall just remove the -q64 from
>> the LTCFLAGS define.
>> If you wanted to consider making this more automatic you could set
>> a condition such that when
>> OBJECT_MODE=64 the flag -q64 is added, otherwise - not used.
>>
>> FYI!
>>
>> regards,
>>
>> Michael
>>
>>
>
>
Re: -q64 flag - gets in the way
Posted by Branko Čibej <br...@apache.org>.
On 08.12.2017 19:32, William A Rowe Jr wrote:
> On Fri, Dec 8, 2017 at 5:49 AM, Branko Čibej <br...@apache.org> wrote:
>> On 08.12.2017 12:35, Joe Orton wrote:
>>> On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote:
>>>> They trust the compiler to do the right things, so there is no special
>>>> sauce added to apr-config. Respective build flags land in
>>>> /usr/lib/apr-1/build/
>>>> /usr/lib64/apr-1/build/
>>> We do have to hack /usr/bin/apr-1-config to do:
>>>
>>> CPPFLAGS=`pkg-config --variable=CPPFLAGS apr-1`
>>>
>>> because that file has to be identical across both 32- and 64-bit builds.
>>> Otherwise we get RPM file conflicts when trying to install both i686 and
>>> x86_64 apr-devel at the same time.
>>>
>>> Because there is no way to actually thread the choice of arch through
>>> pkg-config and the myriad /usr/bin/*-config files, this stuff is a gross
>>> hack, isn't really widely used in practice, and I don't see much point
>>> in trying to solve "properly". It's quite likely 32-bit arches will all
>>> be dead by the time we managed it :)
> Considering I might have parallel libs for Intel and ARM and Power
> at this point, lib/ and lib64/ is sort of an underwhelming hack. But
> the autogunk arch cross-compile model for lib/ is helpful.
>
>> Ooh, I'm getting a 64-bit RPi? Sounds fabulous. :)
> If you gain a RPi 3, you have one. You're just probably running a
> 32-bit OS... unless you want to spin up a 64-bit kernel for ARMv8.
> With 1GB and limited 'disk', I'd avoid spinning a dual-arch kernel.
>
> How 32 vs 64 libs are managed is an architecture choice, Michael
> would probably want to follow IBM's example in the case of AIX.
Ack to all of the above. I've been thinking about how to solve this
problem in generic APR; but I've come to the conclusion that there's
simply no sane way to do that for all supported platforms. The best we
can do is try to make the platform/arch/cross combinations build and
work (patches welcome); packaging and deployment are somebody else's
problem.
My rather facetious point was that 32-bit architectures are not at all
likely to go away soon ... IoT will be chock-full of them and I bet
they'll all need an HTTP server. After all, it's essential that the "70%
done" event from the toaster can start the coffee machine's morning shot
workflow and that it's all controlled in a ReSTful way by the app on the
smart watch. Breakfast should be ready when the alarm rings, not 10
minutes later, eh.
-- Brane
Re: -q64 flag - gets in the way
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Dec 8, 2017 at 5:49 AM, Branko Čibej <br...@apache.org> wrote:
> On 08.12.2017 12:35, Joe Orton wrote:
>> On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote:
>>> They trust the compiler to do the right things, so there is no special
>>> sauce added to apr-config. Respective build flags land in
>>> /usr/lib/apr-1/build/
>>> /usr/lib64/apr-1/build/
>> We do have to hack /usr/bin/apr-1-config to do:
>>
>> CPPFLAGS=`pkg-config --variable=CPPFLAGS apr-1`
>>
>> because that file has to be identical across both 32- and 64-bit builds.
>> Otherwise we get RPM file conflicts when trying to install both i686 and
>> x86_64 apr-devel at the same time.
>>
>> Because there is no way to actually thread the choice of arch through
>> pkg-config and the myriad /usr/bin/*-config files, this stuff is a gross
>> hack, isn't really widely used in practice, and I don't see much point
>> in trying to solve "properly". It's quite likely 32-bit arches will all
>> be dead by the time we managed it :)
Considering I might have parallel libs for Intel and ARM and Power
at this point, lib/ and lib64/ is sort of an underwhelming hack. But
the autogunk arch cross-compile model for lib/ is helpful.
> Ooh, I'm getting a 64-bit RPi? Sounds fabulous. :)
If you gain a RPi 3, you have one. You're just probably running a
32-bit OS... unless you want to spin up a 64-bit kernel for ARMv8.
With 1GB and limited 'disk', I'd avoid spinning a dual-arch kernel.
How 32 vs 64 libs are managed is an architecture choice, Michael
would probably want to follow IBM's example in the case of AIX.
Re: -q64 flag - gets in the way
Posted by Branko Čibej <br...@apache.org>.
On 08.12.2017 12:35, Joe Orton wrote:
> On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote:
>> They trust the compiler to do the right things, so there is no special
>> sauce added to apr-config. Respective build flags land in
>> /usr/lib/apr-1/build/
>> /usr/lib64/apr-1/build/
> We do have to hack /usr/bin/apr-1-config to do:
>
> CPPFLAGS=`pkg-config --variable=CPPFLAGS apr-1`
>
> because that file has to be identical across both 32- and 64-bit builds.
> Otherwise we get RPM file conflicts when trying to install both i686 and
> x86_64 apr-devel at the same time.
>
> Because there is no way to actually thread the choice of arch through
> pkg-config and the myriad /usr/bin/*-config files, this stuff is a gross
> hack, isn't really widely used in practice, and I don't see much point
> in trying to solve "properly". It's quite likely 32-bit arches will all
> be dead by the time we managed it :)
Ooh, I'm getting a 64-bit RPi? Sounds fabulous. :)
-- Brane
Re: -q64 flag - gets in the way
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote:
> They trust the compiler to do the right things, so there is no special
> sauce added to apr-config. Respective build flags land in
> /usr/lib/apr-1/build/
> /usr/lib64/apr-1/build/
We do have to hack /usr/bin/apr-1-config to do:
CPPFLAGS=`pkg-config --variable=CPPFLAGS apr-1`
because that file has to be identical across both 32- and 64-bit builds.
Otherwise we get RPM file conflicts when trying to install both i686 and
x86_64 apr-devel at the same time.
Because there is no way to actually thread the choice of arch through
pkg-config and the myriad /usr/bin/*-config files, this stuff is a gross
hack, isn't really widely used in practice, and I don't see much point
in trying to solve "properly". It's quite likely 32-bit arches will all
be dead by the time we managed it :)
Regards, Joe
Re: -q64 flag - gets in the way
Posted by Michael <ai...@felt.demon.nl>.
On 06/12/2017 17:06, William A Rowe Jr wrote:
> They trust the compiler to do the right things, so there is no special
> sauce added to apr-config. Respective build flags land in
> /usr/lib/apr-1/build/
> /usr/lib64/apr-1/build/
>
> So, that's one sort of workaround to your quandry. It's something we
> really didn't spend a lot of time designing around in 2001 and was left
> to individual distributors to solve as time went on.
I really do not like "lib|lib64" approaches - but if that is all there is:
Either package with -64 in the package name (and use, e.g, /opt/httpd64
and /opt/httpd32 as prefixes,
then a "user" can set symbolic links - and - also only build against
static apr and apr-util libraries.
Then they are not "installed" during run-time, only available on the
packaging server.
When I get that far I'll let you know (if you are interested).
Michael
Re: -q64 flag - gets in the way
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Correct, in that your installed apr_*.h files indicate the behavior of
the library.
That behavior varies between 32 and 64 bit. We also install apr-config for
consumers to pick up the compile flags, and it's obviously not possible to
have two identically named /usr/local/bin/* utilities. At least, not
two parallel
*-dev packages.
Fedora, for example, bends over backwards to acomodate parallel install,
so they end up with an interesting replacement of apr.h;
/* This file is here to prevent a file conflict on multiarch systems. A
* conflict will occur because apr.h has arch-specific definitions.
*
* DO NOT INCLUDE THE NEW FILE DIRECTLY -- ALWAYS INCLUDE THIS ONE INSTEAD. */
#if defined(__i386__)
#include "apr-i386.h"
#elif defined(__ia64__)
#include "apr-ia64.h"
#elif defined(__powerpc64__)
#include "apr-ppc64.h"
#elif defined(__powerpc__)
#include "apr-ppc.h"
#elif defined(__s390x__)
#include "apr-s390x.h"
#elif defined(__s390__)
#include "apr-s390.h"
#elif defined(__x86_64__)
#include "apr-x86_64.h"
#else
#error "This apr-devel package does not work your architecture?"
#endif
They trust the compiler to do the right things, so there is no special
sauce added to apr-config. Respective build flags land in
/usr/lib/apr-1/build/
/usr/lib64/apr-1/build/
So, that's one sort of workaround to your quandry. It's something we
really didn't spend a lot of time designing around in 2001 and was left
to individual distributors to solve as time went on.
Good luck!
Bill
On Wed, Dec 6, 2017 at 8:01 AM, Michael <ai...@felt.demon.nl> wrote:
> On 04/12/2017 03:56, William A Rowe Jr wrote:
>
> On Dec 3, 2017 15:09, "Michael" <ai...@felt.demon.nl> wrote:
>
> On 17/11/2017 13:48, Michael Felt wrote:
>
>
> On 11/13/2017 7:46 AM, William A Rowe Jr wrote:
>
> So, when we prepare source packages, we are using vendor or raw autocruft
> packages... Depending on which release, this varies every by a specific RM.
>
> Well, I was hoping to be able to dual-build (i.e., 32 and 64-bit in one
> package apr and apr-util - but it seems I'll have to package the
> seperately) - lots of lines (sorry) - but there are differences in include
> files that would make me uncomfortable to have a dual package now. And, no
> real suggestion on how to make one. So, it seems keeping the -q64 flag for
> 64-bit is a good idea (to prevent mixes) - and I'll just manually add -q32
> to my 32-bit package.
>
>
> ----------
>
> Michael,
>
> To reiterate, if you want a change, the right way is the arch and host
> flags to autoconf, and the correct translations within libtool. Further
> discussion actually belongs to autoconf and libtool maintainers IMO, unless
> it is our override.
>
> Thanks William - I'll take a look at the auto* tools additional options.
>
> I was thinking dual (i.e., 32-bit and 64-bit) library support is not going
> to be possible - because the include files generated depend on the bit-mode
> during compile, e.g.
>
> diff -ru X32/opt/include/apr-1/apr.h X64/opt/include/apr-1/apr.h
> --- X32/opt/include/apr-1/apr.h 2017-11-30 18:19:54 +0000
> +++ X64/opt/include/apr-1/apr.h 2017-11-30 18:16:20 +0000
>
> ...
>
> /* And APR_UINT64_T_FMT */
> -#define APR_UINT64_T_FMT "llu"
> +#define APR_UINT64_T_FMT "lu"
>
> /* And APR_UINT64_T_HEX_FMT */
> -#define APR_UINT64_T_HEX_FMT "llx"
> +#define APR_UINT64_T_HEX_FMT "lx"
>
> ...
>
> Also something I need to look at is why somethings toggle support.
>
> diff -ru X32/opt/include/apr-1/apr.h X64/opt/include/apr-1/apr.h
> --- X32/opt/include/apr-1/apr.h 2017-11-30 18:19:54 +0000
> +++ X64/opt/include/apr-1/apr.h 2017-11-30 18:16:20 +0000
> @@ -267,7 +267,7 @@
> /* APR Feature Macros */
> #define APR_HAS_SHARED_MEMORY 1
> #define APR_HAS_THREADS 1
> -#define APR_HAS_SENDFILE 1
> +#define APR_HAS_SENDFILE 0
> #define APR_HAS_MMAP 1
> #define APR_HAS_FORK 1
> #define APR_HAS_RANDOM 1
> @@ -277,7 +277,7 @@
> #define APR_HAS_UNICODE_FS 0
> #define APR_HAS_PROC_INVOKED 0
> #define APR_HAS_USER 1
> -#define APR_HAS_LARGE_FILES 1
> +#define APR_HAS_LARGE_FILES 0
>
> 32-bit says it has both SENDFILE and LARGE_FILES. While I could just be
> surprised about SENDFILE differences - 32-bit plus LARGE_FILES is perhaps
> needed to get LARGE_FILE support with 32-bit (and it is zero because it is
> never tested, just assumed when 64-bit?)
>
> Anyway - I'll look at the auto* tools to see what effect additional
> arguments have on things (although, normally I would just call ./configure
> and not the auto* tools) within the files apr-1-config, apr_rules.mk and
> build-1/libtool
>
>
>
> My own preference is to force -q64/32 on the actual CC, LD, AR commands
> etc. At that point, all autoconf choices aught to resolve correctly.
>
>
Re: -q64 flag - gets in the way
Posted by Michael <ai...@felt.demon.nl>.
On 04/12/2017 03:56, William A Rowe Jr wrote:
> On Dec 3, 2017 15:09, "Michael" <ai...@felt.demon.nl> wrote:
>
> On 17/11/2017 13:48, Michael Felt wrote:
>
>>
>> On 11/13/2017 7:46 AM, William A Rowe Jr wrote:
>>
>>> So, when we prepare source packages, we are using vendor or raw autocruft
>>> packages... Depending on which release, this varies every by a specific RM.
>>>
> Well, I was hoping to be able to dual-build (i.e., 32 and 64-bit in one
> package apr and apr-util - but it seems I'll have to package the
> seperately) - lots of lines (sorry) - but there are differences in include
> files that would make me uncomfortable to have a dual package now. And, no
> real suggestion on how to make one. So, it seems keeping the -q64 flag for
> 64-bit is a good idea (to prevent mixes) - and I'll just manually add -q32
> to my 32-bit package.
>
>
> ----------
>
> Michael,
>
> To reiterate, if you want a change, the right way is the arch and host
> flags to autoconf, and the correct translations within libtool. Further
> discussion actually belongs to autoconf and libtool maintainers IMO, unless
> it is our override.
Thanks William - I'll take a look at the auto* tools additional options.
I was thinking dual (i.e., 32-bit and 64-bit) library support is not
going to be possible - because the include files generated depend on the
bit-mode during compile, e.g.
diff -ru X32/opt/include/apr-1/apr.h X64/opt/include/apr-1/apr.h
--- X32/opt/include/apr-1/apr.h 2017-11-30 18:19:54 +0000
+++ X64/opt/include/apr-1/apr.h 2017-11-30 18:16:20 +0000
...
/* And APR_UINT64_T_FMT */
-#define APR_UINT64_T_FMT "llu"
+#define APR_UINT64_T_FMT "lu"
/* And APR_UINT64_T_HEX_FMT */
-#define APR_UINT64_T_HEX_FMT "llx"
+#define APR_UINT64_T_HEX_FMT "lx"
...
Also something I need to look at is why somethings toggle support.
diff -ru X32/opt/include/apr-1/apr.h X64/opt/include/apr-1/apr.h
--- X32/opt/include/apr-1/apr.h 2017-11-30 18:19:54 +0000
+++ X64/opt/include/apr-1/apr.h 2017-11-30 18:16:20 +0000
@@ -267,7 +267,7 @@
/* APR Feature Macros */
#define APR_HAS_SHARED_MEMORY 1
#define APR_HAS_THREADS 1
-#define APR_HAS_SENDFILE 1
+#define APR_HAS_SENDFILE 0
#define APR_HAS_MMAP 1
#define APR_HAS_FORK 1
#define APR_HAS_RANDOM 1
@@ -277,7 +277,7 @@
#define APR_HAS_UNICODE_FS 0
#define APR_HAS_PROC_INVOKED 0
#define APR_HAS_USER 1
-#define APR_HAS_LARGE_FILES 1
+#define APR_HAS_LARGE_FILES 0
32-bit says it has both SENDFILE and LARGE_FILES. While I could just be
surprised about SENDFILE differences - 32-bit plus LARGE_FILES is
perhaps needed to get LARGE_FILE support with 32-bit (and it is zero
because it is never tested, just assumed when 64-bit?)
Anyway - I'll look at the auto* tools to see what effect additional
arguments have on things (although, normally I would just call
./configure and not the auto* tools) within the files apr-1-config,
apr_rules.mk and build-1/libtool
>
> My own preference is to force -q64/32 on the actual CC, LD, AR commands
> etc. At that point, all autoconf choices aught to resolve correctly.
>
Re: -q64 flag - gets in the way
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Dec 3, 2017 15:09, "Michael" <ai...@felt.demon.nl> wrote:
On 17/11/2017 13:48, Michael Felt wrote:
>
>
> On 11/13/2017 7:46 AM, William A Rowe Jr wrote:
>
>> So, when we prepare source packages, we are using vendor or raw autocruft
>> packages... Depending on which release, this varies every by a specific RM.
>>
>
Well, I was hoping to be able to dual-build (i.e., 32 and 64-bit in one
package apr and apr-util - but it seems I'll have to package the
seperately) - lots of lines (sorry) - but there are differences in include
files that would make me uncomfortable to have a dual package now. And, no
real suggestion on how to make one. So, it seems keeping the -q64 flag for
64-bit is a good idea (to prevent mixes) - and I'll just manually add -q32
to my 32-bit package.
----------
Michael,
To reiterate, if you want a change, the right way is the arch and host
flags to autoconf, and the correct translations within libtool. Further
discussion actually belongs to autoconf and libtool maintainers IMO, unless
it is our override.
My own preference is to force -q64/32 on the actual CC, LD, AR commands
etc. At that point, all autoconf choices aught to resolve correctly.