Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

[ios] Improve geometry method definitions #12445

Merged
merged 4 commits into from
Jul 24, 2018
Merged

Conversation

friedbunny
Copy link
Contributor

@friedbunny friedbunny commented Jul 19, 2018

Fixes #12079.

Here’s my (potentially incorrect) understanding of this fix: MGLMapPointForCoordinate() was extern-defined in a C header, but implemented in an Obj-C++ source file and mangled as a C++ symbol. FOUNDATION_EXTERN is C++-aware and will force C-style symbol mangling, which fixes the undefined symbol issue in consumer Obj-C projects (#12079).

You can verify the change in symbol mangling using nm:

Before:

00000000000d3b21 T __Z24MGLMapPointForCoordinate22CLLocationCoordinate2Dd

After:

00000000000a0c01 T _MGLMapPointForCoordinate

This PR also:

  • Moves MGL_EXPORT for two private methods to MGLGeometry_Private.h, rather than defining them with the implementation.
  • Adds internal docs for MGLPointRounded() and removes obsolete iOS 7 compatibility.

/cc @1ec5 @julianrex @kkaefer @asheemmamoowala

@friedbunny friedbunny added iOS Mapbox Maps SDK for iOS build refactor labels Jul 19, 2018
@friedbunny friedbunny added this to the ios-v4.3.0 milestone Jul 19, 2018
@friedbunny friedbunny self-assigned this Jul 19, 2018
@friedbunny friedbunny requested review from 1ec5 and julianrex July 19, 2018 18:51
Copy link
Contributor

@julianrex julianrex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

Copy link
Contributor

@1ec5 1ec5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You learn something new every day. Great find. Should this fix be in the changelogs?

@@ -100,7 +98,7 @@ CLLocationDirection MGLDirectionBetweenCoordinates(CLLocationCoordinate2D firstC

CGPoint MGLPointRounded(CGPoint point) {
#if TARGET_OS_IPHONE || TARGET_OS_SIMULATOR
CGFloat scaleFactor = [UIScreen instancesRespondToSelector:@selector(nativeScale)] ? [UIScreen mainScreen].nativeScale : [UIScreen mainScreen].scale;
CGFloat scaleFactor = [UIScreen mainScreen].nativeScale;
Copy link
Contributor

@1ec5 1ec5 Jul 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the iOS 7 compatibility that’s being removed, by the way. Removal of iOS 8 compatibility might be similarly subtle in the future.

/cc @lloydsheng

@friedbunny friedbunny added the needs changelog Indicates PR needs a changelog entry prior to merging. label Jul 19, 2018
Copy link
Contributor

@asheemmamoowala asheemmamoowala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does MGLSubexpressionsWithJSONObjects in NSExpression+MGLPrivateAdditions.h also need the modified extern?

Do you think it would be beneficial to use FOUNDATION_EXTERN everywhere so that the code is consistent in how functions are exported. Would also prevent copy-🍝 from allowing this in the future.

@friedbunny
Copy link
Contributor Author

friedbunny commented Jul 24, 2018

Per @asheemmamoowala’s review:

Does MGLSubexpressionsWithJSONObjects in NSExpression+MGLPrivateAdditions.h also need the modified extern?

You’re correct that this function could also suffer from the same mangling issue as MGLMapPointForCoordinate(), but as a private symbol this doesn’t appear to matter and our usage doesn’t suffer from any symbol unavailability issues.

Before:

00000000000a5247 t __Z32MGLSubexpressionsWithJSONObjectsP7NSArray

After:

00000000000a5247 t _MGLSubexpressionsWithJSONObjects

Do you think it would be beneficial to use FOUNDATION_EXTERN everywhere so that the code is consistent in how functions are exported. Would also prevent copy-🍝 from allowing this in the future.

This seems prudent to me — switching all of the externs in our darwin code to FOUNDATION_EXTERN only changes the two symbols already mentioned in this issue, but it does provide us with a modicum of safety/consistency with no downsides that I’m aware of (other than, perhaps, being something we’ll have to remember to do).

Our docs even remain the same, since it’s just an alias:

screen shot 2018-07-24 at 6 04 26 pm

`MGLMapPointForCoordinate()` was `extern`-defined in a C header, but implemented in an Obj-C++ source file and mangled as a C++ symbol. `FOUNDATION_EXTERN` is C++-aware and will force C-style symbol mangling, which fixes the undefined symbol issue in consumer Obj-C projects.
`UIScreen.nativeScale` is available beginning in iOS 8, so the conditional is no longer necessary.
FOUNDATION_EXTERN is an alias for extern in most cases, but also covers us in the event that a method could be mismangled by the compiler as C++ (when we want C-style mangling, for Obj-C compatibility).
@friedbunny friedbunny force-pushed the fb-geometry-externs branch from 43547f2 to cdd3553 Compare July 24, 2018 22:15
@friedbunny friedbunny removed the needs changelog Indicates PR needs a changelog entry prior to merging. label Jul 24, 2018
@friedbunny friedbunny merged commit cdd3553 into master Jul 24, 2018
@friedbunny friedbunny deleted the fb-geometry-externs branch July 24, 2018 22:55
Copy link
Member

@kkaefer kkaefer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@1ec5 1ec5 added the macOS Mapbox Maps SDK for macOS label Aug 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
build iOS Mapbox Maps SDK for iOS macOS Mapbox Maps SDK for macOS refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Undefined symbols for architecture x86_64: "_MGLMapPointForCoordinate"
5 participants