apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: -q64 flag - gets in the way
Date Wed, 06 Dec 2017 16:06:22 GMT
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 <aixtools@felt.demon.nl> wrote:
> On 04/12/2017 03:56, William A Rowe Jr wrote:
>
> On Dec 3, 2017 15:09, "Michael" <aixtools@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.
>
>

Mime
View raw message