MacDownApp / macdown

Open source Markdown editor for macOS.
https://macdown.uranusjr.com/
9.44k stars 1.09k forks source link

Build failed in Xcode 10.1 #1051

Open briantully opened 5 years ago

briantully commented 5 years ago

Showing Recent Messages

Cycle details:
→ That command depends on command in Target 'MacDown': script phase “[CP] Embed Pods Frameworks”
→ Target 'MacDown' has copy command from '/Users/brian.tully/Library/Developer/Xcode/DerivedData/MacDown-gxwdfssocsvkvufuhhdvwuydzcpv/Build/Products/Debug/macdown' to '/Users/brian.tully/Library/Developer/Xcode/DerivedData/MacDown-gxwdfssocsvkvufuhhdvwuydzcpv/Build/Products/Debug/MacDown.app/Contents/SharedSupport/bin/macdown'
○ Target 'MacDown' has compile command with input '/Users/brian.tully/Sites/macdown/MacDown/Images.xcassets'
○ That command depends on command in Target 'MacDown': script phase “[CP] Copy Pods Resources”
briantully commented 5 years ago

In addition:

Ld DerivedData/MacDown/Build/Products/Release/macdown normal x86_64
    cd /Users/brian.tully/Sites/macdown
    export MACOSX_DEPLOYMENT_TARGET=10.8
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -L/Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Products/Release -L/Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Products/Release/GBCli -F/Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Products/Release -filelist /Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Intermediates.noindex/MacDown.build/Release/macdown-cmd.build/Objects-normal/x86_64/macdown.LinkFileList -mmacosx-version-min=10.8 -Xlinker -object_path_lto -Xlinker /Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Intermediates.noindex/MacDown.build/Release/macdown-cmd.build/Objects-normal/x86_64/macdown_lto.o -fobjc-arc -fobjc-link-runtime -ObjC -lGBCli -framework Foundation -lPods-macdown-cmd -Xlinker -dependency_info -Xlinker /Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Intermediates.noindex/MacDown.build/Release/macdown-cmd.build/Objects-normal/x86_64/macdown_dependency_info.dat -o /Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Products/Release/macdown

ld: warning: directory not found for option '-L/Users/brian.tully/Sites/macdown/DerivedData/MacDown/Build/Products/Release/GBCli'
ld: library not found for -lGBCli
clang: error: linker command failed with exit code 1 (use -v to see invocation)
briantully commented 5 years ago

However I can see in the output of bundle exec pod install command that it is installed:

╰─ bundle exec pod install
Analyzing dependencies
Downloading dependencies
Using GBCli (1.1)
Using JJPluralForm (2.1)
Using LibYAML (0.1.4)
Using M13OrderedDictionary (1.1.0)
Using MASPreferences (1.3)
Using PAPreferences (0.5)
Using Sparkle (1.18.1)
Using handlebars-objc (1.4.5)
Using hoedown (3.0.7)
Generating Pods project
Integrating client project
Sending stats
Pod installation complete! There are 9 dependencies from the Podfile and 9 total pods installed.
FranklinYu commented 5 years ago

Have you switched to the old build system as mentioned in #1018?

Ok I saw your comment there, but I cannot reproduce. Hope someone else can help.

briantully commented 5 years ago

Thanks @FranklinYu

I spent some time this morning digging through it again and think I figured out a workaround.

For me, what gave me a successful build was to do the following:

After running the prerequisite commands listed in the README (xcode-select --install, git submodule init, git submodule update, bundle exec pod install, etc) to run the following:

bundle exec pod update

Which seems to fix the missing GBCli linker issue.

In addition, follow the recommendation in #1018 to change the workspace settings to the legacy build system.

Suprisingly, what's not listed in the README, and the only way I figured out how to get an actual built MacDown.app, was to run the following command from the repo root:

./Tools/build_for_release.py [private_key]

Where private_key can just be a string. It doesn't seem to get enforced as being an actual private key format.

Hope that helps someone else!

legoming commented 5 years ago

same error for me:

Ld /Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Products/Debug/macdown normal x86_64
    cd /Users/ming/workspace/macdown
    export MACOSX_DEPLOYMENT_TARGET=10.8
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -L/Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Products/Debug -L/Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Products/Debug/GBCli -F/Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Products/Debug -filelist /Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Intermediates.noindex/MacDown.build/Debug/macdown-cmd.build/Objects-normal/x86_64/macdown.LinkFileList -mmacosx-version-min=10.8 -Xlinker -object_path_lto -Xlinker /Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Intermediates.noindex/MacDown.build/Debug/macdown-cmd.build/Objects-normal/x86_64/macdown_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -fobjc-arc -fobjc-link-runtime -ObjC -lGBCli -framework Foundation -lPods-macdown-cmd -Xlinker -dependency_info -Xlinker /Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Intermediates.noindex/MacDown.build/Debug/macdown-cmd.build/Objects-normal/x86_64/macdown_dependency_info.dat -o /Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Products/Debug/macdown
ld: warning: directory not found for option '-L/Users/ming/Library/Developer/Xcode/DerivedData/MacDown-hevgvdjjihwxhdgyvunhjjoimyvy/Build/Products/Debug/GBCli'
ld: library not found for -lGBCli
clang: error: linker command failed with exit code 1 (use -v to see invocation)
legoming commented 5 years ago

bundle exec pod update

do this is not fixed issue on my computer.

legoming commented 5 years ago

@FranklinYu can you help this issue? How can I build on Mojave?

legoming commented 5 years ago

./Tools/build_for_release.py [private_key]

Finally, build success with command.

briantully commented 5 years ago

Build has started failing again with the latest changes in master.

Pre-build cleaning...
Running external scripts...
Building application archive...
Traceback (most recent call last):
  File "./Tools/build_for_release.py", line 145, in <module>
    main(sys.argv)
  File "./Tools/build_for_release.py", line 82, in main
    '-scheme', 'MacDown',
  File "/Users/brian.tully/Sites/macdown/Tools/macdown_utils.py", line 27, in execute
    cmd=' '.join(args), code=proc.returncode, output=stderr
macdown_utils.CommandError: "/usr/bin/xcodebuild archive -workspace ../MacDown.xcworkspace -scheme MacDown" failed with error 65.
 2019-05-31 11:34:23.535 xcodebuild[53592:15397674] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 39. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug.
** ARCHIVE FAILED **

The following build commands failed:
    PhaseScriptExecution [CP]\ Copy\ Pods\ Resources /Users/brian.tully/Library/Developer/Xcode/DerivedData/MacDown-gxwdfssocsvkvufuhhdvwuydzcpv/Build/Intermediates.noindex/ArchiveIntermediates/MacDown/IntermediateBuildFilesPath/MacDown.build/Release/MacDown.build/Script-1E02F0A95AAEBCEF65493F5F.sh
(1 failure)

In linting all plist and strings files, it seems to be related to the sk translations that appear to get pulled down from transiflex on build:

cd MacDown/Localization/sk.lproj
find . -name '*.strings' -exec plutil -lint {} \;
2019-05-31 11:37:07.243 plutil[54452:15403741] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 215. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug.
./MainMenu.strings: Unexpected character / at line 1
./MPHtmlPreferencesViewController.strings: OK
./MPDocument.strings: Cannot parse a NULL or zero-length data
./MPExportPanelAccessoryViewController.strings: OK
2019-05-31 11:37:07.617 plutil[54456:15403837] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 39. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug.
./Localizable.strings: Unexpected character / at line 1
./InfoPlist.strings: OK
./MPGeneralPreferencesViewController.strings: OK
./MPEditorPreferencesViewController.strings: OK
./MPTerminalPreferencesViewController.strings: OK
./MPMarkdownPreferencesViewController.strings: OK

I've tried deleting the sk.lproj directory and rebuilding but then I get an error saying that the translations couldn't be copied, likely because I removed the target directory.

Any idea how to resolve?

rschiang commented 4 years ago

As I managed to get MacDown built under Xcode 11.2, I'm clearing up some issues from above. (CC @FranklinYu if these should be split to separate issues):

I'll see if I can turn them into PRs later.

FranklinYu commented 4 years ago
  • The problem raised by @legoming was related to the removal of system-wide SDK headers starting from macOS 10.14.

I'm not sure whether that's the reason. I don't have /user/include but still failed to reproduce the error.

rschiang commented 4 years ago

@FranklinYu macOS 10.14 headers package for /usr/include is merely a mitigation for compatibility, and I believe what Apple is trying to lure us into is to refrain from putting headers there.

If we set up build path correctly to use xcrun -sdk macosx -show-sdk-path, then the headers should be found working just fine under that path. If you can't reproduce the problem, maybe that means the configuration in HEAD already works?

(This might need to be tested on a CI machine or a clean installation though, to make sure we're using the new build system correctly and not some user-specific PATH magic. 🤔 )