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

configure does not handle FreeBSD current (i.e. 10) correctly, leading to build failures #6072

Closed
vicuna opened this issue Jul 10, 2013 · 5 comments

Comments

@vicuna
Copy link

@vicuna vicuna commented Jul 10, 2013

Original bug ID: 6072
Reporter: mundkur
Status: closed (set by @xavierleroy on 2015-12-11T18:21:02Z)
Resolution: fixed
Priority: low
Severity: major
OS: FreeBSD
OS Version: 10
Target version: 4.01.0+dev
Fixed in version: 4.01.0+dev
Category: configure and build/install

Bug description

Ocaml does not build on FreeBSD-Current, which has version 10.0. The issue is in the configure script, which has this clause to detect shared library support:

*-*-linux-gnu|*-*-linux|*-*-freebsd[3-9]*|*-*-openbsd*|*-*-netbsd*|*-*-gnu*)

This fails for freebsd-current, which reports:

$ config/gnu/config.guess
x86_64-unknown-freebsd10.0

$ uname -r
10.0-CURRENT

Steps to reproduce

'make world.opt' fails at:

../../boot/ocamlrun ../../tools/ocamlmklib -o unix -oc unix -ocamlopt '../../ocamlcompopt.sh' -linkall unix.cmx unixLabels.cmx
../../ocamlcompopt.sh -shared -o unix.cmxs -I . unix.cmxa
-o: not found
File "caml_startup", line 1:
Error: Error during linking
*** Error code 2

Stop.
make: stopped in /pool/users/pm524/build/ocaml/otherlibs/unix

Additional information

This may indicate a deeper bug: although configure reports (erroneously) that shared libraries are not supported, the build still tries to build one.

Configuration for the bytecode compiler:
C compiler used........... gcc
options for compiling..... -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE
options for linking....... -lm -lcurses -pthread
shared libraries not supported

File attachments

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 12, 2013

Comment author: @damiendoligez

About the "deeper bug": there are two kinds of support for dynamic linking, which are tested independently by the configure script:

  1. "Dynamic loading of shared libraries" and "shared libraries are supported": this is for the byte-code interpreter to use dynamic linking to load external primitives. If you don't have that, you have to compile your byte-code executables with -custom.

  2. "native dynlink": this is dynamic linking of native-code files, and production of dynamically-linkable files.

In your case, it looks like configure decided that (1) is not supported, but (2) is.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 12, 2013

Comment author: @damiendoligez

I propose the attached patch. Could someone test it on a machine with FreeBSD 10 ?

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 12, 2013

Comment author: mundkur

The patch doesn't quite work, since "$target" is set to "x86_64-unknown-freebsd10.0". The following clause works:

*-*-linux-gnu|*-*-linux|*-*-freebsd[3-9]*|*-*-freebsd[1-9][0-9].[0-9]|*-*-openbsd*|*-*-netbsd*|*-*-gnu*)

It might be too brittle against future breakage to be used as is, but indicates the matching needed.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 16, 2013

Comment author: @damiendoligez

In fact, a star was missing in my patch. The idea is to recognize any freebsd with at least two digits in its version number.

New patch uploaded.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 17, 2013

Comment author: @damiendoligez

I have applied my second patch in the 4.01 branch (rev 13900). Feel free to reopen this PR if there is a problem.

@vicuna vicuna closed this Dec 11, 2015
@vicuna vicuna added this to the 4.01.0 milestone Mar 14, 2019
@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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant