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

Building 64 bit for OS X 10.6 builds some libraries as 32 bit #5247

Closed
vicuna opened this issue Apr 4, 2011 · 8 comments
Closed

Building 64 bit for OS X 10.6 builds some libraries as 32 bit #5247

vicuna opened this issue Apr 4, 2011 · 8 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Apr 4, 2011

Original bug ID: 5247
Reporter: @johnwhitington
Status: closed (set by @xavierleroy on 2015-12-11T18:04:29Z)
Resolution: not a bug
Priority: normal
Severity: major
Version: 3.12.0
Category: ~DO NOT USE (was: OCaml general)
Monitored by: "Alan Schmitt"

Bug description

Hi,

Have tried this with both ./configure and ./configure -cc "gcc -m64" -as "as -arch x86_64" -aspp "gcc -m64 -c". I'm using XCode 4.0

fresh:ocaml-3.12.0 john$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)

fresh:ocaml-3.12.0 john$ lipo -info /usr/local/lib/ocaml/*.a
Non-fat file: /usr/local/lib/ocaml/bigarray.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/camomile.a is architecture: i386
Non-fat file: /usr/local/lib/ocaml/dbm.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/dynlink.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/graphics.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libasmrun.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libasmrunp.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libbigarray.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libcamlrun.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libcamlstr.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libgraphics.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libmldbm.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libnums.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libstr.a is architecture: i386
Non-fat file: /usr/local/lib/ocaml/libthreads.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libthreadsnat.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/libunix.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/nums.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/stdlib.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/stdlib.p.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/str.a is architecture: x86_64
Non-fat file: /usr/local/lib/ocaml/unix.a is architecture: x86_64

As you can see, camomile.a and libstr.a are 32 bit here.

@vicuna
Copy link
Author

vicuna commented Apr 4, 2011

Comment author: @johnwhitington

Actually, it seems to not be possible to build any architecture of ocaml with Xcode 4 at the moment. The 32-bit version fails in make opt.opt with

../ocamlcompopt.sh -nostdlib unix.cmxa -g -I stdlib -I ../otherlibs/unix ocamlbuild/ocamlbuild_executor.cmx ocamlbuild/ocamlbuild_pack.cmx ocamlbuild/ocamlbuild_unix_plugin.cmx ocamlbuild/ocamlbuild.cmx -o ocamlbuild/ocamlbuild.native
ld: in ocamlbuild/ocamlbuild_pack.o, in section __DATA,__data reloc 1: sectionForAddress(0x4028458) address not in any section for architecture i386
collect2: ld returned 1 exit status
File "caml_startup", line 1, characters 0-1:
Error: Error during linking
Exit code 2 while executing this command:
../ocamlcompopt.sh -nostdlib unix.cmxa -g -I stdlib -I ../otherlibs/unix ocamlbuild/ocamlbuild_executor.cmx ocamlbuild/ocamlbuild_pack.cmx ocamlbuild/ocamlbuild_unix_plugin.cmx ocamlbuild/ocamlbuild.cmx -o ocamlbuild/ocamlbuild.native
make: *** [ocamlbuild.native] Error 2

@vicuna
Copy link
Author

vicuna commented Apr 4, 2011

Comment author: @johnwhitington

A second thought about the original bug content: I think camomile.a and libstr.a might just have been left over from the previous installation?

I'm afraid I'm in the midst of degrading to XCode 3 and earlier gcc so I can get back to work, so I can't find out what the timestamps on those files were.

@vicuna
Copy link
Author

vicuna commented Apr 5, 2011

Comment author: @johnwhitington

So, it turns out that even with XCode 3.2 under OS X 10.6, you need

sudo ln /usr/local/lib/ocaml/libcamlstr.a /usr/local/lib/ocaml/libstr.a

to get things working. So perhaps there have been changes to how gcc deals with things like -lstr, or changes to how ocaml detects what library names are needed on OS X.

@vicuna
Copy link
Author

vicuna commented May 3, 2011

Comment author: @damiendoligez

I can't reproduce this problem with XCode 3.2.3 on Mac OS 10.6.
Can you give us a repro case? What do you mean by "to get things working"?

@vicuna
Copy link
Author

vicuna commented May 9, 2011

Comment author: @johnwhitington

Have just reinstalled the OS and XCode from scratch here, and can't reproduce either. So the bug is just XCode 4, as listed in the first comment.

@vicuna
Copy link
Author

vicuna commented May 27, 2011

Comment author: Alan Schmitt

I'm seeing a similar problem: there is no "libstr.a" and any attempt to link with "-lstr" fail. Creating a link from libstr.a to libcamlstr.a solves the issue.

I'm using 10.6.7, Xcode 3.5.2, and ocaml 3.12.0 (compiled with godi).

@vicuna
Copy link
Author

vicuna commented Oct 7, 2011

Comment author: @johnwhitington

Note that this issue is still present in XCode 4.1, OS X 10.7 Lion, OCaml 3.12.1 64 bit.

(I built OCaml using mmottl's patch to 3.12.1 in bug 4863).

sudo ln /usr/local/lib/ocaml/libcamlstr.a /usr/local/lib/ocaml/libstr.a

still fixes it.

@vicuna
Copy link
Author

vicuna commented Apr 10, 2012

Comment author: @damiendoligez

libstr.a was changed to libcamlstr.a to make OCaml compatible with a third-party library (commit 9318: "resolve name clash with ossp-str").

But this should be transparent to almost all OCaml users because you are not supposed to link with "-lstr". You should just link with str.cma, and the OCaml compiler pulls the right .a file (which happens to be libcamlstr.a).
If you want to link your program with gcc or ld, you'll need to track the change from libstr.a to libcamlstr.a.

So yes, the libstr.a file was a leftover from a previous build. I'm pretty sure the same is true of camomile.a since it's not part of the OCaml distribution.

@vicuna vicuna closed this as completed Dec 11, 2015
@vicuna vicuna added the bug label Mar 20, 2019
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