On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <swift-dev@swift.org
> wrote:
>
> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <
> swift-dev@swift.org> wrote:
> >
> > Hi,
> >
> > I made an experimental MSVC port. Of cause, dllimport/dllexport and the
> driver for linking and many other part is not implemented. But dynamic
> linking was possible with some trick.
> >
> > I think it is useful for designing, my observation about the
> experimental building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll
> and linking of Hello.exe - its source has only 'print("Hello")'.
> >
> > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
> > Hello.obj needed defined in libswift*.dll
> > _swift_getExistentialTypeMetadata,
> > _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
> > _TMSS,
> > _TZvOs7Process5_argcVs5Int32,
> > swift_bufferAllocate, ....
> > Some of above are dllexported by the macro, but _T* are not. Maybe, it
> generated by swiftc.exe.
> > I used the utility 'dlltool.exe' from Cygwin/MinGW world. It extracts
> all symbols and generates 'allsymbol.def'.
> > With that .def, I could build the all-symbol-dllexported
> libswiftCore.dll.
> > (I'm hoping we can build it without this trick.)
>
> The _T symbols are emitted by the Swift compiler. You should modify
> swiftc's IRGen to generate public symbols with LLVM's "dllexport" storage
> class when targeting Windows.
https://github.com/apple/swift/pull/2080 is a first cut attempt to do this.
>
> -Joe
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
