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

add windows support #190

Merged
merged 9 commits into from Oct 20, 2014

Conversation

Projects
None yet
2 participants
@fdopen
Member

fdopen commented Oct 14, 2014

  • Windows specific details for dlopen are mentioned in dl.mli
  • PosixTypes are mapped to appropriate windows types (if possible) or
    to int64_t. I didn't rearrange module dependecies to avoid breaking
    the interface. But a resorting at the next major release would be nice.
  • It currently only works with mingw-w64/gcc , msvc support would
    require more workarounds. Msvc doesn't support many used c99 headers
    and features (stdint.h, complex.h, etc.). And only mingw provides
    helper functions to simplify the work (e.g. own printf implementation that
    supports the usual format strings, unistd.h header)
  • flexlink currently doesn't provide an equivalent to
    '-Wl,--no-as-needed'. Forcing flexlink to pass it at the right
    position to the mingw-w64 toolchain is non-trivial. I modified the
    test cases to avoid this issue on windows.
  • test cases run without errors, but it might be not deterministic.
    (e.g. when I've linked it in a different way, dlsym selected another
    sprintf implementation from a windows dll)
@yallop

This comment has been minimized.

Show comment
Hide comment
@yallop

yallop Oct 14, 2014

Member

Thanks! I'll take a proper look at this soon. The 4.00.1 Travis build is currently failing because |> is not available

Member

yallop commented Oct 14, 2014

Thanks! I'll take a proper look at this soon. The 4.00.1 Travis build is currently failing because |> is not available

@yallop

This comment has been minimized.

Show comment
Hide comment
@yallop

yallop Oct 14, 2014

Member

Thanks for the fix. Could you please rebase against trunk? I think the recent changes (324c2b0, 69f1994) to use OCaml 4.02.1 instead of 4.02.0 should fix the remaining Travis failure.

Member

yallop commented Oct 14, 2014

Thanks for the fix. Could you please rebase against trunk? I think the recent changes (324c2b0, 69f1994) to use OCaml 4.02.1 instead of 4.02.0 should fix the remaining Travis failure.

Show outdated Hide outdated src/ctypes/posix_types_stubs.c
#define EXPOSE_ALIGNMENT(TYPENAME) \
value ctypes_alignmentof_ ## TYPENAME(value unit) \
{ \
struct s { char c; int64_t t; }; \

This comment has been minimized.

@yallop

yallop Oct 16, 2014

Member

I don't understand this definition. What's int64_t doing here?

@yallop

yallop Oct 16, 2014

Member

I don't understand this definition. What's int64_t doing here?

This comment has been minimized.

@fdopen

fdopen Oct 16, 2014

Member

Types that don't have any equivalent under windows are mapped to int64_t (arbitrary decision). There must be such a function, because of the external declarations inside posixTypes.ml (and these functions are called during startup, I can't throw an exception or similar).

I didn't want to introduce something like camlp4.macro to the build process. And I didn't want to remove the posixTypes declarations completely for the windows build process. Some types are ansi c (e.g. time_t, clock_t ) and some of the other types could also be useful.

@fdopen

fdopen Oct 16, 2014

Member

Types that don't have any equivalent under windows are mapped to int64_t (arbitrary decision). There must be such a function, because of the external declarations inside posixTypes.ml (and these functions are called during startup, I can't throw an exception or similar).

I didn't want to introduce something like camlp4.macro to the build process. And I didn't want to remove the posixTypes declarations completely for the windows build process. Some types are ansi c (e.g. time_t, clock_t ) and some of the other types could also be useful.

@yallop yallop modified the milestone: ctypes 0.4 Oct 16, 2014

@yallop

This comment has been minimized.

Show comment
Hide comment
@yallop

yallop Oct 20, 2014

Member

I think we're just about ready to merge. Could you please rebase one last time against trunk to resolve the conflict with b642409?

Member

yallop commented Oct 20, 2014

I think we're just about ready to merge. Could you please rebase one last time against trunk to resolve the conflict with b642409?

@fdopen

This comment has been minimized.

Show comment
Hide comment
@fdopen

fdopen Oct 20, 2014

Member

I've rebased it and changed Makefile.tests according to #196

Member

fdopen commented Oct 20, 2014

I've rebased it and changed Makefile.tests according to #196

yallop added a commit that referenced this pull request Oct 20, 2014

@yallop yallop merged commit 3404c85 into ocamllabs:master Oct 20, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@yallop yallop referenced this pull request Oct 20, 2014

Closed

Using ctypes on Windows #184

@fdopen fdopen deleted the fdopen:windows branch Apr 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment