Command + Drag does not work (Apple)

[tresf]

Edit: Thanks to @follower for the hint.... Here's the workaround:

[...] through random key mashing happened to make drag copy appear to work by pressing command (butterfly) and option (alt) simultaneously!

Edit: 2024 @tresf: It appears Ctrl can fix this on nightly versions, but it's very hard to time properly.

---

On Mac, the Ctrl shortcuts generally map to the Command button.

On current master branch, the Command + Drag should clone a Piano roll or BB Editor segment but does not.

Steps to reproduce:

1. Using OSX 10.7 or higher, install latest master branch (mirror available here: @tresf/lmms-1.1.91-mac10.8.dmg)
2. Create a piano roll segment
3. Try to clone it using a modifier key
4. No modifier keys work for cloning, instead a Right Click, Copy and Right Click, Paste is needed.

[follower]

This also affects automation on OS X as it's not possible to drag a control knob etc onto the automation track.

In both cases the drag "ghost" image of the block/control appears but it doesn't have the green "+" copy symbol.

It works on RC1.

Tested on Mac OS X 10.8.x with the 1.1.91 DMG file from OP.

[tresf]

Marking for 1.2 milestone.

This bug is really making usability of 1.2 difficult on Mac.

This may be a Qt5 problem. This works perfectly fine in the 1.1.3 installer which was packaged with Qt4.

[follower]

When did the Qt5 change happen? FWIW it works fine with the 1.2.0-RC1 / lmms-1.1.90-mac10.7.dmg file.

[tresf]

When did the Qt5 change happen

Between RC1 and the upcoming RC2 per https://github.com/LMMS/lmms/issues/2611

[tresf]

Moving to #2611. This is a blocker for Qt5 release. Help appreciated.

[tresf]

Some more details for those that may be able to help...

AFAIK, the check happens here: src/core/Track.cpp#L657

if( m_trackView->trackContainerView()->allowRubberband() == true &&
        me->button() == Qt::LeftButton )
    {
        if( m_trackView->trackContainerView()->rubberBandActive() == true )
        {
            // Propagate to trackView for rubberbanding
            selectableObject::mousePressEvent( me );
        }
+       else if ( me->modifiers() & Qt::ControlModifier )
+       {
+           if( isSelected() == true )
+           {
+               m_action = CopySelection;
+           }
            else
            {
                m_action = ToggleSelected;
            }
        }
        else if( !me->modifiers() )
        {
            if( isSelected() == true )
            {
                m_action = MoveSelection;
            }
        }
    }

And according to the Qt 5.7 docs, this logic should still be valid...

"Note: On OS X, the ControlModifier value corresponds to the Command keys on the Macintosh keyboard, and the MetaModifier value corresponds to the Control keys. The KeypadModifier value will also be set when an arrow key is pressed as the arrow keys are considered part of the keypad."

But some people claim modifiers() can't be trusted. Is this an underlying Qt5 bug? Note, we use Qt 5.5 due to a bug with macdeployqt on 5.6 so if this is a bug with 5.5, we may between a rock and a hardplace in regards to moving from Qt4.

[BaraMGB]

@tresf have you tried to code that hard? I've seen that somewhere in the code with that flower string. “⌘”

[tresf]

I've seen that somewhere in the code with that flower string.

Thanks for the hint however what you are referring to is most likely just a translated tool-tip.

[tresf]

Edit: Turns out the "bug" is with qDebug per https://bugreports.qt.io/browse/QTBUG-47316. The underlying data is fine. This can be observed by changing qDebug() << txt.toUtf8() to qDebug() << txt.toUtf8().data().

Back to the drawing board...

---

Ok... I'm fairly certain the bug stems from the StringPairDrag object constructor. For some reason with Qt5 it's escaping the newlines and double quotes.

According to qDebug()

Qt4:

"tco:0:<?xml version="1.0"?>
<!DOCTYPE>
..."

Qt5:

"tco:0:<?xml version=\"1.0\"?>\n<!DOCTYPE>
..."

As far as I understand, this will break the construction of a new TCO because it's contents will be unparsable, but if that's the case, why only on Mac?

Thoughts? Is there a flag or a QDomDocument QString or toUTF8() change I'm missing here?

[jasp00]

To help you, someone should work on Linux, add traces (fprintf(stderr,) to the drag and drop process, and make a new branch so that you can test and provide feedback.

[tresf]

The above video demonstrates what happens when replacing Qt::ControlModifier with Qt::ShiftModifier (and subsequently actually using the Shift key while dragging).

After a few hours of testing, I'm fairly certain Qt 5.5 is ignoring any mousePressEvent when ⌘ Command key is being pressed. All other shortcuts seem to be OK.

I tested this by placing a qDebug statement at the top of TrackContentObjectView::mousePressEvent(...).

This debug line shows with all modifiers except ⌘ Command. I think this is a bug with Qt5.5 and possibly others...

Components that are broken with this behavior:

• Clone track using ⌘ Command + Drag handle
• Linking Automation Editor using ⌘ Command + (any control within LMMS)
• ⌘ Command + Drag-cloning patterns inside Song Editor, Beat/Bassline Editor

[teeberg]

In Qt 5.6, at least that part seems to work for me. With

qDebug() << "TCOV::mousePressEvent" << me->modifiers();

as the first line in TrackContentObjectView::mousePressEvent and dragging while holding ⌘, I get

TCOV::mousePressEvent QFlagsQt::KeyboardModifiers(ControlModifier)

as expected. The pattern still doesn't copy though. Where I see it break down is around TrackContentWidget::dropEvent, which gets triggered in Qt 4.8.7, but not in 5.6.1.

I'm having trouble installing 5.5, so I'm afraid I can't reproduce what you're seeing. Do you have a 5.6 installation at hand to see whether that maybe fixes what you're seeing?

[tresf]

In Qt 5.6, at least that part seems to work for me. With

Sorry, it was a mistake on my part...

I've put debug statements all over Track.cpp and you're right, it IS firing on mousePressEvent. It's not firing on TrackContentWidget::dropEvent. That seems to be the place where the actual pasteSelection code gets fired.

If you blindly replace all instances of Qt::ControlModifier with Qt::ShiftModifier it all works with the shift key.

Side note... DON'T use Qt::MetaModifier because Mac translates Ctrl to toggle the Qt::RightButton and then all of the Qt::LeftButton logic fails. ⚱

[teeberg]

I just recompiled with Qt 5.6.2 (released yesterday) and it works 🚀

[tresf]

If macdeployqt is still broken then we can't package with 5.6 due to QTBUG-53533 although I do consider this stellar news.

See also https://github.com/LMMS/lmms/issues/2862.

Ugh... https://bugreports.qt.io/browse/QTBUG-53533 https://bugreports.qt.io/browse/QTBUG-56814 https://bugreports.qt.io/browse/QTBUG-54086

[tresf]

@teeberg I've patched the installation process to use the 5.5 version of the macdeployqt for bundling, while still using the latest version for compiling here https://github.com/tresf/lmms/commit/fc899978f8cf3a5724863778f0c7e78969b1ec34. This allows us to use Qt 5.6 or higher without suffering from #2862.

Unfortunately Option + Drag is still broken.

I'm starting to wonder if this issue is related to the build environment I'm using (10.9 for backwards compat reasons).

I'd happily use a newer build environment if we can keep backwards compatibility for older MacOS versions.

[tresf]

To put the "Why do we build on 10.8 anyway?" conversation into some context, I tried running a 10.11 build on 10.8 and this is what I get:

1. Splash screen
2. Crash while attempting to initialize the audio devices

https://gist.github.com/tresf/b52f70300970b6f733e9c173bf43fc84

Option+Drag is a crucial feature for LMMS. How crucial is having backward compatibility?

BTW, Removing SDL gets us a bit further but still crashes...

https://gist.github.com/tresf/b55e2d7510921f42c30bfaff8a65aa4c

The Command + Drag bug may be caused by this:

https://bugreports.qt.io/browse/QTBUG-48795

[follower]

For the record, I'd be disappointed but understanding if LMMS chose not to support OS X 10.8 as that's what I'm currently on. (I suspect older hardware running older OS versions might be more common due to less compelling Mac hardware releases of late but could be wrong.)

By way of comparison, for similar FLOSS creative apps (but with presumably larger dev teams):

• Blender supports Mac OS X 10.6+ (Snow Leopard onward)
• Gimp supports Mac OS X 10.6+ (Snow Leopard onward)
• Inkscape supported Mac OS X 10.7+ (and somewhat 10.5-10.6) for the immediate previous release but currently has no OS X binaries of the latest release.
• Ardour supports Mac OS X x 10.5+ (Leopard onward)

If the decision is made not to support older versions the release notes need to be updated to indicate this--currently they still say OS X 10.7 is the minimum supported.

[follower]

In terms of the error message from running the 10.11 build--did you have the correct minimum system version set for compilation?

There seems to be two primary causes of backward compatibility issues with OS X apps:

• Incorrect minimum OS version settings causing use of new optimisations/features rather than backward compatible shims (fixable).
• Newer features not supported by older releases.

[follower]

Also, the later "Symbol not found: ___exp10f" error messages seems to potentially fit into the first category:

• http://llvm.org/docs/doxygen/html/TargetLibraryInfo_8cpp_source.html#l00282

[tresf]

10.8 was the planned dev environment for the 1.2 release. Many patches for 1.2 were due to Apple being mid-stdc++ during this SDK.

Tha said, the Command + Drag bug is the only outstanding, but one of which has dire consequences.

If you have time to address this, we'd be happy to release a 10.8 DMG.

Furthermore, we'd be happy to release one anyway if it's worth living without automation.

[tresf]

Perhaps a 3rd option is a 10.8 Qt4 release. The new theme has many bugs with Qt4 on Mac (some of which make it impossible to read file names) but it does fix the Command Drag bug. Thoughts welcome.

[tresf]

If the decision is made not to support older versions the release notes need to be updated to indicate this--currently they still say OS X 10.7 is the minimum supported.

@follower, we've added 10.8 build to our downloads page. Can you please test this on 10.7 so we know how best to document in the release notes? (Warning, it still suffers the Command + Drag bug)

https://lmms.io/download/#mac

[follower]

Ummm, so, this is just a quick comment (I've got some other thoughts but they'll have to wait :) )...

I just tested the 10.8 build (1.2.0-rc2.6) (thanks for going to the effort of building that, btw :) ) and through random key mashing happened to make drag copy appear to work by pressing command (butterfly) and option (alt) simultaneously! It seems to work with at least beat blocks and automation knob drag copies...

Should this be working? :D

[follower]

While I'm at it... my "other thoughts" mentioned above was that when I was researching OS X version support for my earlier post I totally forgot about Mixxx which is particularly relevant both because it's another audio application and it uses QT:

• "Mixxx 2.0.0 supports Mac OS X 10.5+ (Intel)"

My initial investigations suggest they're now using QT5 (?) I could be wrong on that.

These files might be of interest in relation to the linking issues [edit: #2862] I seem to recall:

• https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/qt5.py
• https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/qt4.py
• https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/osx/OSConsX.py
• https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/osx/otool.py

I'm not sure if they use command drag anywhere--I initially thought they did for copying tracks into crates but it seems like the "+"/drag copy happens without key modifiers.

Thanks again for pursuing this issue. :)

[follower]

It appears to be affected by #2892 also (can't remember if I've mentioned that previously) except more severely as the menu backgrounds are white, not grey.

Was able to play around with making some "music" with the kick and triple osc keyboard, so it seems like a promising start. :)

Since it seems to be working okay I'll switch to using that version until I encounter something problematic.

[tresf]

Should this be working? :D

No it shouldn't, but it makes more sense why it's being ignored if it thinks an additional modifier key need to be held. How well does it work? Is it intermittent or does it work 100% of the time when ALT is held? If that is the case, we may be able to workaround it. I'm intrigued now.

These files might be of interest in relation to the linking issues [edit: #2862] I seem to recall:

Thanks. Take a look at this unused script. https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/unused/create_mixxx_dmg.sh#L39-L149

This has been superseded by the otool.py script they've authored themselves, used by scons here: https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/osx/OSConsX.py#L275-L282

Long story short... It's a lot of work due to a botched upstream tool. :/

It appears to be affected by #2892 also (can't remember if I've mentioned that previously) except more severely as the menu backgrounds are white, not grey.

Right, the new theme has a bunch of issues with Qt4 on Mac. We can likely fix 99% of these in style.css if someone wants to take the time to hack at it. Wait are you saying you suffer these bugs on Qt5?

[follower]

How well does it work? Is it intermittent or does it work 100% of the time when ALT is held?

AFAICT (from the admittedly limited testing with BB & knob drag/copy I've done so far) it works 100% of the time.

I'm intrigued now.

You and me both. :)

Long story short... It's a lot of work due to a botched upstream tool. :/

Yeah, I suspected that was the case.

Incidentally, I'm a little confused about how all the different aspects (e.g. {build OS version; QT version; run OS version} vs. {app runs; drag+copy works} ) interact, so wanted to clarify the current situation. Primarily because I wasn't sure if OS X 10.11 release (which uses QT 5.6?) has a correctly working drag+copy? Does it?

Also, wanted to know if you tried setting 10.8 as the min OS version when building on 10.11?

Wait are you saying you suffer these bugs on Qt5?

Yes (the mouse pointer is not visible in the screenshot but was on the "Empty" template entry):

As far as I recall, I deleted the .lmmsrc.xml file before testing...

The menu icons in the classic theme display correctly.

(Also, I get crashes on exit most of the time that seem related to QT clean-up operations but that's been pretty constant with all the versions I've used and doesn't seem to prevent correct function.)

[tresf]

Primarily because I wasn't sure if OS X 10.11 release (which uses QT 5.6?) has a correctly working drag+copy? Does it?

Yes, it does both Qt5.5 and Qt5.6 have working option-drag (Qt5.6 is useless due to the macdeployqt bug, but I have a workaround to get us on Qt5.6 if needed. The option-drag bug seems to be a combination of Qt5 + Xcode version which causes it. Builds created on 10.11 + Xcode 8 don't seem to suffer the option-drag bug. I believe it to be the newer version of Xcode which makes the difference.

also, wanted to know if you tried setting 10.8 as the min OS version when building on 10.11?

Yes, about a month ago but not for this latest build. AFAIK, that just sets the SDK to an older version, which needs to be explicitly installed anyway (no backward compat magic going on). I had a 10.11 build environment running Xcode 5.5.1 successfully (and then this setting would toggle between Xcode 7/8 and Xcode 5) but other than helping dodge the legacy build environment bugs and legacy brew dependencies the outputted app wasn't any better (same drag bug occurred). This 10.8 build was done directly on 10.8.

[follower]

AFAIK, that just sets the SDK to an older version, which needs to be explicitly installed anyway (no backward compat magic going on).

My understanding is that there is actually some backward compatibility magic going on, with the correct configuration. :)

Specifically, CMAKE_OSX_DEPLOYMENT_TARGET is used to set -mmacosx-version-min but if it is used to set the minimum version, then CMAKE_OSX_SYSROOT needs to be set to use the newer SDK version that is installed on the build host.

CMakeCache.txt includes the following comments (re: weak-linking):

//Minimum OS X version to target for deployment (at runtime); newer
// APIs weak linked. Set to empty string for default value.
CMAKE_OSX_DEPLOYMENT_TARGET:STRING=

//The product will be built against the headers and libraries located
// inside the indicated SDK.
CMAKE_OSX_SYSROOT:STRING=

In addition to weak-linking (which presumably can have its own issues) it also disables certain optimisations for backward compatibility (via):

 "The compiler and linker are capable of using features and performing optimizations that do not work on older OS versions. -mmacosx-version-min tells the tools what OS versions you need to work with, so the tools can disable optimizations that won't run on those OS versions. If you need to run on older OS versions then you must use this flag.

"The downside to -mmacosx-version-min is that the app's performance may be worse on newer OS versions then it could have been if it did not need to be backwards-compatible. In most cases the differences are small."

For additional details: see & see

Also, I'm uncertain how far back this works.

But, I assume we'd want:

CMAKE_OSX_DEPLOYMENT_TARGET=10.8 # Maybe even 10.7?
CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk # Or wherever it is.

So, it might be worth trying, in order to hopefully enable a return to a single download and deal with some of the version-related issues...

[follower]

Having said all that, I have also noticed a more specific version of the workaround behavior--and it turns out the use of option may have been a red herring:

1) Press command. 2) Start the drag by left-clicking and then moving. 3) Before you get to the drop zone release the command key. 4) Drag over the drop zone and the + indicator should now appear. 5) Release the left button and the drop should occur.

The key cough seems to be that command needs to pressed to start the drag operation but immediately released.

Edit:

I should note that I tested this by dragging a "track mute" button to an automation track (but I just confirmed it works with a song editor segment). Also, this was on a laptop trackpad.

Since it still doesn't display the + icon until you're over the drop zone this is still just a workaround.

[follower]

A couple of other things I just noticed:

• Holding down command over the Song Editor switches to "Edit mode (select and move)" and highlights the appropriate toolbar icon.

• Holding down command over the Piano Roll appears to switch to "Select mode" but doesn't highlight the related toolbar icon.

(I wondered if maybe this double duty might have been interfering.)

• A message QPixmap::grabWidget is deprecated, use QWidget::grab() instead appears in the console. (But changing to use grab() appears not to make any difference.)

• The use of start() in StringPairDrag::StringPairDrag() is apparently deprecated but changing it doesn't appear to make any difference.

• When dragging an automatable button, even when the "drop" "succeeds" the icon goes flying back to its original location--not sure if this is intended behavior or not.

Anyway, I guess we'll see if the compilation configuration changes help otherwise perhaps I'll look at digging in some more...

[follower]

Two things in relation to https://github.com/LMMS/lmms/issues/2890#issuecomment-340539041:

1) I noticed the following caution in a random email I encountered ([Development] HEADS UP: OSX build requirements for 5.7):

we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment target on 10.8, where std::exceptions could not be caught ... compiling against 10.8 sdk solved that issue. so an xcode/sdk update is not necessarily a no-brainer and there might be a benefit to still compile with different xcode versions against different sdks.

So it seems we may still encounter issues if we took this approach.

2) @tresf I was wondering if you would be able to test the approach using CMAKE_OSX_DEPLOYMENT_TARGET & CMAKE_OSX_SYSROOT that I suggested in the comment above? Or could I modify .travis.yml and/or .travis/osx..script.sh myself to trigger such a test? Thanks.

[tresf]

@tresf I was wondering if you would be able to test the approach

Historically, we don't handle exceptions in 99.9% of code, so this seems a bit wishful thinking.

Installing the old SDK should be possible without Travis.

https://stackoverflow.com/questions/10335747/how-to-download-xcode-dmg-or-xip-file/10335943#10335943

I've always done legacy SDKs on the originally intended OS. I don't have time to test this theory, but if someone can prove it, I'd be happy to switch the way I produce the builds to fix this issue.

[follower]

BTW re: https://github.com/LMMS/lmms/issues/2890#issuecomment-264785105 (Symbol not found: _AudioUnitInitialize) it seems it may have been the result of a 10.11 SDK bug.

See:

• "AudioUnitInitialize not found when running on 10.10"

• "xcode7-beta AudioUnit.framework dyld failure"

• "Backwards compatibility of binaries linked against OS X 10.11 SDK"

The workarounds suggested at the time were to change the link order or to link against OS X 10.10 SDK.

[follower]

Thanks for your reply, @tresf.

@tresf I was wondering if you would be able to test the approach

Historically, we don't handle exceptions in 99.9% of code, so this seems a bit wishful thinking.

I seem to have not communicated my point re: the exception handling issue mentioned in the email I linked--I can see now that the email quote can be read two ways.

But the upshot is: if LMMS doesn't handle exceptions then we shouldn't run into issues with compiling for 10.8 with the 10.11 SDK. So, pretend I never quoted that email. :)

Installing the old SDK should be possible without Travis.

https://stackoverflow.com/questions/10335747/how-to-download-xcode-dmg-or-xip-file/10335943#10335943

Nothing I am suggesting requires anyone to install an old SDK.

I don't have time to test this theory, but if someone can prove it, I'd be happy to switch the way I produce the builds to fix this issue.

Unfortunately I can't test this theory because I don't have access to macOS 10.10, 10.11 or 10.12.

However, as I understand it, the following is the only patch that is necessary:

diff --git a/.travis/osx..script.sh b/.travis/osx..script.sh
index 30c9387..3d0f4a3 100644
--- a/.travis/osx..script.sh
+++ b/.travis/osx..script.sh
@@ -5,4 +5,7 @@ if [ $QT5 ]; then
         export CMAKE_PREFIX_PATH="$(brew --prefix qt55)"
 fi

+export CMAKE_OSX_DEPLOYMENT_TARGET=10.8
+export CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
+
 cmake $CMAKE_FLAGS -DUSE_WERROR=OFF ..

Note: This patch does not require the 10.8 SDK to be installed. Explicitly setting CMAKE_OSX_SYSROOT means that the existing 10.11 SDK will be used but some "magic" will automatically be used by the compiler/linked/SDK to ensure the resulting binary can still run on 10.8 (since it is set as the deployment target).

(I'm working on the assumption--because security--that I can't just submit a PR that would change .travis/osx..script.sh and have Travis automatically run it but, if there is nothing stopping me from doing that, I can give it a try.)

[tresf]

I've made attempts to force lower SDK version without the SYSROOT flag and the bug was still present. I'll have to test it, thanks.

Yes, you can build artifacts using a PR that never gets merged, but even easier you can turn on Travis for your fork and upload to transfer.sh from your fork. Travis allows this from any repo. You can even remove the Win/Lin stuff to save on CPU cycles.

[tresf]

Here's a 10.11 artifact using Qt5.5, CMAKE_OSX_DEPLOYMENT_TARGET=10.8 and CMAKE_OSX_SYSROOT=[...]/MacOSX10.11.sdk.

Note, it's built from master, not stable-1.2.

https://github.com/tresf/lmms/releases/download/vmaster/lmms-1.2.0-rc4.235-mac10.11.dmg

[tresf]

Note, although this build succeeded, it didn't actually make LMMS work on 10.8.

[follower]

Thanks for testing the build with that configuration @tresf, I really appreciate it! :)

Current status

I can confirm I get the same result as you (splash screen is displayed and then this crash):

dyld: lazy symbol binding failed: Symbol not found: ___strlcpy_chk
  Referenced from: /Volumes/LMMS 1.2.0-rc4.235/LMMS.app/Contents/MacOS/../Frameworks/libSDL2-2.0.0.dylib
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___strlcpy_chk
  Referenced from: /Volumes/LMMS 1.2.0-rc4.235/LMMS.app/Contents/MacOS/../Frameworks/libSDL2-2.0.0.dylib
  Expected in: /usr/lib/libSystem.B.dylib

Trace/BPT trap: 5

More crash detail:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Dyld Error Message:
  Symbol not found: ___strlcpy_chk
  Referenced from: /Volumes/VOLUME/LMMS.app/Contents/MacOS/../Frameworks/libSDL2-2.0.0.dylib
  Expected in: /usr/lib/libSystem.B.dylib

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   dyld                                0x00007fff6c0bf09d dyld_fatal_error + 1
1   dyld                                0x00007fff6c0c2048 dyld::fastBindLazySymbol(ImageLoader**, unsigned long) + 139
2   libdyld.dylib                       0x00007fff866398ee dyld_stub_binder_ + 13
3   ???                                 0x000000010cee8008 0 + 4511924232
4   libSDL2-2.0.0.dylib                 0x000000010ce53b64 0x10ce4c000 + 31588
5   libSDL2-2.0.0.dylib                 0x000000010ced1d9c 0x10ce4c000 + 548252
6   libSDL2-2.0.0.dylib                 0x000000010ced1564 0x10ce4c000 + 546148
7   libSDL2-2.0.0.dylib                 0x000000010ce542c7 0x10ce4c000 + 33479
8   libSDL2-2.0.0.dylib                 0x000000010ce5192b 0x10ce4c000 + 22827
9   lmms                                0x000000010c5633d8 AudioSdl::AudioSdl(bool&, Mixer*) + 168
10  lmms                                0x000000010c519cdc Mixer::tryAudioDevices() + 492
11  lmms                                0x000000010c519ac6 Mixer::initDevices() + 294
12  lmms                                0x000000010c4f9f86 LmmsCore::init(bool) + 566
13  lmms                                0x000000010c589c25 GuiApplication::GuiApplication() + 1941
14  lmms                                0x000000010c4c64f2 main + 9138
15  libdyld.dylib                       0x00007fff8663b7e1 start + 1

Switching to dummy audio

If I run a different version and change the audio system to Dummy (rather than SDL), and then run your version again then the above error doesn't occur but eventually this error does happen:

dyld: lazy symbol binding failed: Symbol not found: ___exp10
  Referenced from: /Volumes/LMMS 1.2.0-rc4.235/LMMS.app/Contents/MacOS/lmms
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___exp10
  Referenced from: /Volumes/LMMS 1.2.0-rc4.235/LMMS.app/Contents/MacOS/lmms
  Expected in: /usr/lib/libSystem.B.dylib

Trace/BPT trap: 5

More crash detail:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Dyld Error Message:
  Symbol not found: ___exp10
  Referenced from: /Volumes/VOLUME/LMMS.app/Contents/MacOS/lmms
  Expected in: /usr/lib/libSystem.B.dylib

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   dyld                            0x00007fff65e7b09d dyld_fatal_error + 1
1   dyld                            0x00007fff65e7e048 dyld::fastBindLazySymbol(ImageLoader**, unsigned long) + 139
2   libdyld.dylib                   0x00007fff866398ee dyld_stub_binder_ + 13
3   ???                             0x0000000106445008 0 + 4400107528
4   lmms                            0x000000010634242b FxMixerView::FxMixerView() + 859
5   lmms                            0x0000000106345ec7 GuiApplication::GuiApplication() + 2615
6   lmms                            0x00000001062824f2 main + 9138
7   libdyld.dylib                   0x00007fff8663b7e1 start + 1

The errors suggest that at least some of the compilation is still occurring without the correct deployment target, so more recent functionality is still being used. :/

Next

Guess I'll have to try poking at it a bit further--too bad it doesn't quite get us far enough that we could test the drag functionality!

Do you have a build log for this build?

Thanks again for testing this and the tip about getting Travis to run.

(Side note: I just noticed LMMS.app/Contents/Info.plist doesn't seem to specify any minimum OS version requirements.)

[follower]

I've made attempts to force lower SDK version without the SYSROOT flag and the bug was still present.

Yeah, so, in theory the configuration you just used should still use the more recent SDK but with support for earlier ones...

Also, my motivation for this approach is two fold:

1. Be able to return to a single Mac build/download.

2. Fix the drag bug.

So, (1) would be useful even if we didn't manage (2).

But currently, I guess we're on (0). :/

(I also wonder if it would make any difference with a 10.10 SDK but we've probably both got higher priorities than testing that. :) )

[tresf]

@follower which OS were you testing on? Mine did load on 10.11 and the drag didn't work either, but what's interesting is the toolbar toggles when Meta/Option is pressed, so this may be a problem with event propagation.

Anyway, I'm not putting more time into the mixed builds, I'll stick to the same SDK and OS, which has been enough of a challenge on its own.

(Side note: I just noticed LMMS.app/Contents/Info.plist doesn't seem to specify any minimum OS version requirements.)

No, it could probably be calculated as current OS minus 0.2, but I'd rather not bank on Mac keeping the 10.x versioning .

[follower]

Hmmm, actually, referring back to a file I linked in an earlier comment, perhaps we're not specifying the deployment target in a way that LLVM is detecting it correctly--because there's explicit code to handle the most recent functions we're having errors with (via):

   switch (T.getOS()) {
   case Triple::MacOSX:
     // exp10 and exp10f are not available on OS X until 10.9 and iOS until 7.0
     // and their names are __exp10 and __exp10f. exp10l is not available on
     // OS X or iOS.
     TLI.setUnavailable(LibFunc_exp10l);
     if (T.isMacOSXVersionLT(10, 9)) {
       TLI.setUnavailable(LibFunc_exp10);
       TLI.setUnavailable(LibFunc_exp10f);
     } else {
       TLI.setAvailableWithName(LibFunc_exp10, "__exp10");
       TLI.setAvailableWithName(LibFunc_exp10f, "__exp10f");
     }
  break;

[tresf]

Yeah, so, in theory the configuration you just used should still use the more recent SDK but with support for earlier ones...

This would probably work, but we bundle 3rd party libraries that didn't necessarily take this into consideration, so we're packaging other people's problems into our code installers (hence the need to build and test directly on the target platform).

[tresf]

we're not specifying the deployment target in a way that LLVM is detecting it correctly

We are, I just think SDL won't because it's provided as pre-compiled binaries from Homebrew. One idea is to just use homebrew to build everything from scratch, but this would take a long time to setup a build environment as all dependencies would have to build from scratch.

Also, I don't even think Homebrew has a good method for building old versions. If they do, it would be worth a try, but it would take days to set up.

When I setup a 10.8 box, this is done naturally because Homebrew has no interest in storing binaries that old so it builds all of the dependencies (including Qt5, which takes forever) from scratch.

[follower]

Oh...

Okay, so, from looking at MACOSX_DEPLOYMENT_TARGET and CMAKE_OSX_DEPLOYMENT_TARGET it seems perhaps we should be using MACOSX_DEPLOYMENT_TARGET and not CMAKE_OSX_DEPLOYMENT_TARGET:

[Re: CMAKE_OSX_DEPLOYMENT_TARGET] Specify the minimum version of OS X on which the target binaries are to be deployed. CMake uses this value for the -mmacosx-version-min flag and to help choose the default SDK (see CMAKE_OSX_SYSROOT).

If not set explicitly the value is initialized by the MACOSX_DEPLOYMENT_TARGET environment variable, if set, and otherwise computed based on the host platform.

(Although looking at LLVM/CLang's MACOSX_DEPLOYMENT_TARGET docs maybe that case is already handled.)

[tresf]

@follower that's good to know, but I'm still not sure how it's going to be smart enough to go into pre-compiled binaries and make them work with an old OS.

[follower]

Sorry, @tresf I wasn't seeing your replies on GitHub in a browser for some reason...

which OS were you testing on?

10.8.5

Mine did load on 10.11 and the drag didn't work either

:/

what's interesting is the toolbar toggles when Meta/Option is pressed, so this may be a problem with event propagation.

Yeah, I did notice that at one point--does it also do that on the builds that do have working drag?

Anyway, I'm not putting more time into the mixed builds

Yeah, that's fair enough. :) Thanks for trying it out.

(Side note: I just noticed LMMS.app/Contents/Info.plist doesn't seem to specify any minimum OS version requirements.)

No, it could probably be calculated as current OS minus 0.2, but I'd rather not bank on Mac keeping the 10.x versioning .

I guess normally one could use the deployment target/minimum OS version used for compilation but that won't work if we're using pre-packaged binaries.

but we bundle 3rd party libraries that didn't necessarily take this into consideration

Right, I wondered if that was the case.

I just think SDL won't because it's provided as pre-compiled binaries from Homebrew. One idea is to just use homebrew to build everything from scratch, but this would take a long time to setup a build environment as all dependencies would have to build from scratch.

Yeah.

Also, I don't even think Homebrew has a good method for building old versions.

My impression is that they don't. I guess one has to use an older formula from the repository history or something...

When I setup a 10.8 box, this is done naturally because Homebrew has no interest in storing binaries that old so it builds all of the dependencies (including Qt5, which takes forever) from scratch.

I think on more recent OS you can force compilation by specifying not to use "bottles" (i.e. precompiled binaries).

but I'm still not sure how it's going to be smart enough to go into pre-compiled binaries and make them work with an old OS.

Indeed. :D But when I wrote that GitHub hadn't shown me your previous comment yet. :)

So, yeah, yak shaving all the way down...

In conclusion:

• Presumably not currently worth the effort to return to a single version build due to multiple inter-related factors.

• We'll have to live with the drag & drop issue for now until a clear solution appears. (Which isn't that bad since I narrowed down the work around to be when you press/release the Command key only.)

Thanks again!

Edit: For possible future reference:

• Example of runtime conditional symbol use based on OS version: https://github.com/libarchive/libarchive/commit/47bec12b98b173d631f4279b2a9dd01bb7d2183c

• Oh, funny, I think we might actually be seeing some unintended consequences of doing this (the history of which can be found by searching the repository for exp10 & exp10f): https://github.com/LMMS/lmms/blob/28a4eb27f28193461b874eb6f40217e13ad66739/include/lmms_math.h#L37-L39

Edit 2: For possible future reference:

• More re: MACOSX_DEPLOYMENT_TARGET effect: https://github.com/luarocks/luarocks/issues/422#issuecomment-144220836

• "Base SDK and Deployment Target Settings"

• "Explicitly pass an isysroot to avoid the SDKROOT overriding the deployment target."

[tresf]

I guess normally one could use the deployment target/minimum OS version

I don't think so. Apple is supposed to be binary compatible with older and newer OSs. I believe it's +2 and -2, or in the case of current versioning, +0.2, -0.2, but this is math I'd rather not trust, companies are known to skip numbers.

I guess one has to use an older formula from the repository history or something...

I meant from a target OS perspective. The old formula may be needed for compiler features, but to rebuild from scratch against an older SDK -- AND -- not conflicting with the current SDK versions doesn't seem like an available (or documented feature). It may be available through xcode-select path, but sandboxing the Homebrew install from a modern one seems like more work than simply setting up an old machine.

I've gotten a lot of friction from the Mac development community on using and old machine and at times told to stop using Homebrew for building dependencies but whatever. I'm just trying to make the Mac experience as good as the Windows experience. OSX Lion was released 10 years after Windows XP yet our bleeding edge builds still work 99.9% on XP from a single binary whereas Mac needs two binaries.

not currently worth the effort to return to a single version build due to multiple inter-related factors.

It may be worth it, it's just a speculative fix. I can't find evidence it helps the actual bug.

We'll have to live with the drag & drop issue for now until a clear solution appears

Agreed. From an end-user perspective, I do music production on Mac and on Windows so I've been living with it for quite a while. It's not the only obscure shortcut to switch to when I'm on the Mac. :)

But to fix this properly is probably still trapped in the event propagation code. If this is true, the toolbar is a good indication as to the cause. :)

[tresf]

I believe the toolbar/shortcut refactoring was recently done by @BaraMGB in 9b5d379, so this may be a good place to look if building the master branch and trying to prevent the capture of the Meta/Option key.

From what I understand, Qt tries to automagically switch Ctrl to Option for shortcut key purposes and this may be part of the problem, but it's just a guess.