Skip to content

[SR-3635] Swift stdlib gets wrong EH Personality on FreeBSD #46220

Open
@swift-ci

Description

@swift-ci
Previous ID SR-3635
Radar None
Original Reporter nether_cat (JIRA User)
Type Bug
Environment

FreeBSD 11.0-RELEASE

Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: 3a144b0e6f779d3d5ab04e4b3b28d9df

Issue Description:

Currently building Swift on FreeBSD leads to libswiftCore.so having an undefined symbol '__gnustep_objcxx_personality_v0' which is the Exception Handling Personality function from the GNUstep libobjc. This results in undefined symbol errors when trying to run the Swift REPL and when executing binaries build with swiftc as long as you don't link them to GNUstep's Objective-C library. As @belkadan stated in #4804 we shouldn't be linking it. I couldn't find the source for this problem yet. But I found https://github.com/apple/swift-clang/blob/stable/lib/CodeGen/CGException.cpp to be an interesting place to start.

I also like to mention, that my builds on Ubuntu 16.04 seem not to use any EH personality functions. I tried grep and nm, giving results in Swift binary/stdlib on FreeBSD only for __gnustep_objcxx_personality_v0 and on macOS for __objc_personality_v0, __objcxx_personality_v0, __gcc_personality_v0 and __gxx_personality_v0, but no matches on Linux. I believe the usage on macOS is because of the Objective-C/C++ Bridging support, which is not present on Linux and FreeBSD. Please fix 🙂

Metadata

Metadata

Assignees

No one assigned

    Labels

    FreeBSDPlatform: FreeBSDbugA deviation from expected or documented behavior. Also: expected but undesirable behavior.standard libraryArea: Standard library umbrella

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions