On 24 Oct 2009, at 13:36, Jeff Trawick wrote:
On Sat, Oct 24, 2009 at 8:16 AM, Barry Scott <firstname.lastname@example.org
On 22 Oct 2009, at 20:47, Barry Scott wrote:
On 20 Oct 2009, at 22:30, Jeff Trawick wrote:
On Tue, Oct 20, 2009 at 4:54 PM, Barry Scott <email@example.com>
On 20 Oct 2009, at 04:18, Branko Čibej wrote:
Barry Scott wrote:
I think the problem is that configure is used to find out things that
change arch to arch
like void * size rather then using preprocessor detection of those
I wonder, how do you detect the size of void* with the preprocessor in
C? The preprocessor doesn't understand sizeof.
You detect that its a build on mac os x and then use the CPU feature
that the compiler defines to choose 4 or 8. You end up writing code like
its Mac intel 64
I have build subversion and apr twice for i386 and x86_64.
Then I'm writting scripts to merge the two trees of build files
into a single FAT binary kit with FAT libs and header files.
The binary code can be handled this way. But the headers
cannot as some are different. I'm going to have to do something
copy i386 version of apr.h to i386-apr.h
copy x86_64 version of apr.h to x86_64.apr.h
create a wrapper apr.h
Below is details of the diffs I see.
Here is a diff between building for i386 and x86_64.
2009-10-24 12:54:18.000000000 +0100
2009-10-24 12:54:26.000000000 +0100
@@ -100,7 +100,7 @@
#define APU_HAVE_SQLITE2 0
#define APU_HAVE_ORACLE 0
#define APU_HAVE_FREETDS 0
-#define APU_HAVE_ODBC 0
+#define APU_HAVE_ODBC 1
#define APU_HAVE_APR_ICONV 0
#define APU_HAVE_ICONV 1
It seems that ODBC is not in both i386 and x86_64.
Just curious: is that Apple-delivered ODBC, that they chose not to
deliver in both architectures, or some third-party ODBC that configure
found on your system?
This is going to take a bit of effort to track down.
The libodbc.a is for four arch so both i386 and x86_64 should have found it and been happy.
Its not clear to me from the logs while its different.
2009-10-24 12:54:17.000000000 +0100
2009-10-24 12:54:25.000000000 +0100
@@ -239,7 +239,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
Most of the diff here can be avoided by using stdint.h as far as I can see.
Only one I'm not sure of is APR_HAS_LARGE_FILES. Is that set based on
64bit or not?
APR_HAS_LARGE_FILES unfortunately (?) does not simply mean you can use
files larger than 2GB. It effectively means that APR is using LFS
flags in a 32-bit build to support large files.
You can always use large files in a 64-bit build.
(big shrug on the stdint.h comment)
C99 has a header file inttypes.h that provides all the defines you use in APR and more besides.
Its you are happy to assume C99 as a minimum compiler level you can code against inttypes.h
and stop figuring out type information in configure. Otherwise I'd suggest you find out in configure
if inttypes.h is support and use it if it is available otherwise do what you do now.
I don't know how others feel, but I think a helper script could be
bundled with APR to combine the multiple builds, and maybe even run
the two separate builds to start with. It probably wouldn't be
completely generic, but might be useful as-is or at least as an
example to all those APR-on-OS X packagers out there ;)
The problem here you can solve from only APR and APR UTIL.
How will this helper impact on building subversion?
At the moment I configure subversion that configures apr
and apr-util as part of its build.
I welcome anything that will make the situation better,
however I feel that until you are happy to fix the configure
to work with multiple arch it will be of limited help.
You can see the scripts that I'm using to solve this for pysvn.
I use this script to build subversion:
And it uses this script to merge an i386 and x86_64 build tree into a universal tree.
Notice that I have to wrap any header file that has differences between i386 and x86_64.
I'm in the middle of trying to get this all working and would not be surpised to find that
I have bugs in these scripts.