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 <aixto...@felt.demon.nl> wrote: > On 04/12/2017 03:56, William A Rowe Jr wrote: > > On Dec 3, 2017 15:09, "Michael" <aixto...@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. > >
