Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definition of uint64 in caml/config.h conflicts. (MacOSX Snow Leopard, X86_64) #4877

Closed
vicuna opened this issue Sep 30, 2009 · 4 comments
Closed
Labels
Milestone

Comments

@vicuna
Copy link

vicuna commented Sep 30, 2009

Original bug ID: 4877
Reporter: kiyoshi
Status: closed (set by @xavierleroy on 2016-12-07T10:34:35Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.11.1
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: ~DO NOT USE (was: OCaml general)
Related to: #8395 #4164 #6517
Monitored by: monipol

Bug description

Conflict of the uint64 definition prevents to define external functions using Cocoa API.

$ cat test.m
#include <caml/config.h>
#import <Cocoa/Cocoa.h>

$ cc -I /opt/local/lib/ocaml test.m
In file included from /System/Library/Frameworks/Security.framework/Headers/Security.h:24,
from /System/Library/Frameworks/Foundation.framework/Headers/NSURLCredential.h:14,
from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:79,
from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
from test.m:2:
/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:53: error: conflicting types for ‘uint64’
/opt/local/lib/ocaml/caml/config.h:128: error: previous declaration of ‘uint64’ was here
$ sed -n 53p < /System/Library/Frameworks/Security.framework/Headers/cssmconfig.h
typedef uint64_t uint64;
$ grep "typedef.*uint64_t;" /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdint.h
typedef unsigned long long uint64_t;
$ sed -n 128p < /opt/local/lib/ocaml/caml/config.h
typedef ARCH_UINT64_TYPE uint64;
$ grep "#define.*ARCH_UINT64_TYPE" /opt/local/lib/ocaml/caml/config.h
#define ARCH_UINT64_TYPE unsigned long
$

A patch attached to this report will resolve this problem.

I guess ppc64 architecture also has same problem and this patch resolve it.

Additional information

$ uname -v
Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.6.1
BuildVersion: 10B504
$ port version
Version: 1.8.1
$ port list installed | grep ocaml
ocaml @3.11.1 lang/ocaml
$ cc -verson
i686-apple-darwin10-gcc-4.2.1: no input files
$

File attachments

@vicuna
Copy link
Author

vicuna commented Jan 22, 2010

Comment author: monipol

Hello, kiyoshi. Does your patch prevent uint64 from being defined on Mac OS X? What if <caml/config.h> is being used by a non-Cocoa, non-Carbon program that's supposed to build on Mac OS X — wouldn't uint64 need to be defined by OCaml then?

One alternative solution would be config.h to consider a new macro that would determine whether config.h should define those types or not.

For what it's worth, this issue also affects Mac OS 10.5 (Leopard) when building 64-bit programs that use both Cocoa and OCaml.

@vicuna
Copy link
Author

vicuna commented Jan 28, 2010

Comment author: kiyoshi

Hi, monipol.

Does your patch prevent uint64 from being defined on Mac OS X?
No.

My patch only affects lines on "m.h" generated by config script.

Please look at the config file affected by my patch:

echo "#define SIZEOF_PTR $3" >> m.h
echo "#define SIZEOF_SHORT $4" >> m.h

-if test $2 = 8; then
+if test $2 = 8 && $system != macosx; then
echo "#define ARCH_INT64_TYPE long" >> m.h
echo "#define ARCH_UINT64_TYPE unsigned long" >> m.h
echo '#define ARCH_INT64_PRINTF_FORMAT "l"' >> m.h
int64_native=true
else
sh ./runtest longlong.c
case $? in
0) echo "64-bit "long long" integer type found (printf with "%ll")."
echo "#define ARCH_INT64_TYPE long long" >> m.h
echo "#define ARCH_UINT64_TYPE unsigned long long" >> m.h
echo '#define ARCH_INT64_PRINTF_FORMAT "ll"' >> m.h
int64_native=true;;

Execution of original configure script on 64-bit Mac OS X processes 'then' part, so uint64 is defined as "long".
This type is not equals to "long long", the type of uint64 defined in /System/Library/Frameworks/Security.framework/Headers/cssmconfig.h.

In the case of the script my patch applied, "else" pat is executed.
Execution of "runtiest longlong.c" returns 0, so uint64 is defined as "long long", and the result is no type conflict errors.

I think that you can select 64/32-bit binary with C-compiler options so that "runtest sizes.c" returns the expected value:

echo "Checking the sizes of integers and pointers..."
set sh ./runtest sizes.c
case "$2,$3" in
4,4) echo "OK, this is a regular 32 bit architecture."
echo "#undef ARCH_SIXTYFOUR" >> m.h
arch64=false;;
*,8) echo "Wow! A 64 bit architecture!"
echo "#define ARCH_SIXTYFOUR" >> m.h
arch64=true;;
,) echo "This architecture seems to be neither 32 bits nor 64 bits."
echo "Objective Caml won't run on this architecture."
exit 2;;
*) echo "Unable to compile the test program."
echo "Make sure the C compiler $cc is properly installed."
exit 2;;

For example, 'configure -cc "cc -arch x86_64"; make world' on Mac OS X 10.5 will generate 64-bit binaries.

@vicuna
Copy link
Author

vicuna commented Sep 17, 2012

Comment author: @damiendoligez

Watch out, there is a bug in the patch.

This problem should be properly solved when we fix #4164.

@vicuna
Copy link
Author

vicuna commented Aug 27, 2014

Comment author: @xavierleroy

See 6517 for more info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant