macOS: "export DYLD_IMAGE_SUFFIX=_debug" in qmake (".pro") file?

[davecotter]

@jeremy_k i investigated this approach and i don't understand how this can work. I'm trying to avoid having separate "run configurations" for debug and release, inside Qt Creator, so the only thing that is different is the "Build Configuration" (between debug and release). In this screen shot you'll see i have only one Deploy and one Run config, that all of my Build configs use:

Yet still i wish to programmatically set the environment var for debug only, when the app is run from Creator.

@kshegunov I am not following what you're saying. Can you be more explicit with a how-to step? How do i "invoke the shell ... from the invocation of qmake" ?

Do you mean it should be an "Additional Argument" in the qmake build step?

if so, what would be the syntax?

-dave

[kshegunov]

@davecotter said in macOS: "export DYLD_IMAGE_SUFFIX=_debug" in qmake (".pro") file?:

Do you mean it should be an "Additional Argument" in the qmake build step?

No I meant for you to put it in the project file, something along the lines of:

CONFIG(debug, debug|release): system("export DYLD....=_debug");

[davecotter]

@kshegunov oh very interesting. are you sure that that environ var is guaranteed to persist for the actual run of the app, like in the same shell? i'm concerned that the shell instance run during qmake time and the shell instance run to actually open the app may be different instances?

[SGaist]

Hi,

I think there might be some misunderstanding here. This variable shall be set at run time so there's nothing in qmake that will allow you to do that.

qmake is a project manager nothing more.

You will have to set this variable in each debug build variant you have.

You might be able to that more quickly editing the .pro.user file using a text editor. Do not forget to make a copy before modifying it.

[kshegunov]

@davecotter said in macOS: "export DYLD_IMAGE_SUFFIX=_debug" in qmake (".pro") file?:

@kshegunov oh very interesting. are you sure that that environ var is guaranteed to persist for the actual run of the app, like in the same shell? i'm concerned that the shell instance run during qmake time and the shell instance run to actually open the app may be different instances?

Yes, you're right, I didn't think of that x_x ... and @SGaist confirms I'm dead wrong.

[davecotter]

You will have to set this variable in each debug build variant

yeah that's exactly what i'm trying to avoid. I want just ONE "run config" that all my "build configs" use, not one for debug and one for release.

I guess there isn't a way to do this :(

[JonB]

@davecotter
I know nothing about MacOS. Just how early does this DYLD_IMAGE_SUFFIX environment variable need to be set? Is it used prior to loading and running the executable by the OS loader or something, or is it used at runtime once/after your application code starts executing?

[davecotter]

how early does this DYLD_IMAGE_SUFFIX environment variable need to be set?

I don't know, i was just following the advice of this article. I want debug so i can step through the Qt frameworks.

[JonB]

@davecotter
I know, I saw, but it doesn't say anything about when that environment variable gets used. If it's only once your code gets executed, I was thinking you could have runtime code to set the environment variable suitably in debug build only. A different approach if it works for you.

[SGaist]

Before running your application.

That's an environment variable in the same category as LD_LIBRARY_PATH.

[jeremy_k]

It's used when looking up the library name to load, Eg libQt5Core${suffix}.dylib. For non-programmatically loaded libraries, this is effectively when the application process starts executing.

I think it's also used for dlopen(), but I don't know if the value is cached the first time it is accessed, or if updates to the environment variable can be made during the lifetime of the process.

[davecotter]

so, reading deeper, it occurred to me that perhaps this is about building Qt Libraries? I'm not doing that, i'm running my own app, based on existing Qt Libraries... so am i just just thinking too hard? Is it the case that i don't need this at all?

I see that without specifying this in my Run Config, i'm able to debug into Qt Libraries just fine....

?

[JoeCFD]

qputenv(const char *varName, const QByteArray &value) will do it as well in your code in case something else is needed to be set.
varName and value can be set from command line arguments on QtCreator run.

[jeremy_k]

@davecotter said in macOS: "export DYLD_IMAGE_SUFFIX=_debug" in qmake (".pro") file?:

so, reading deeper, it occurred to me that perhaps this is about building Qt Libraries?

DYLD_IMAGE_SUFFIX changes runtime library loading. It's not a build time thing.
man 1 dyld should help clarify, and lists other variables that can be useful.

I see that without specifying this in my Run Config, i'm able to debug into Qt Libraries just fine....

In the macOS copy of Qt 5.15.2 I'm looking at, there's a clang_64/lib/QtCore.framework/
that contains the shared library, and a clang_64/lib/QtCore.framework.dSYM/ with dwarf debug symbols and a python helper for lldb. It looks like this is Apple's version of pdb style separate debugging symbols. man dsymutil has some information.

$ file QtCore.framework/QtCore 
QtCore.framework/QtCore: Mach-O 64-bit dynamically linked shared library x86_64
$ file QtCore.framework.dSYM/Contents/Resources/DWARF/QtCore 
QtCore.framework.dSYM/Contents/Resources/DWARF/QtCore: Mach-O 64-bit dSYM companion file x86_64

[davecotter]

sorry but can you spell out your conclusion? does that mean that i do NOT need to set this env var at all?

[jeremy_k]

@davecotter said in macOS: "export DYLD_IMAGE_SUFFIX=_debug" in qmake (".pro") file?:

sorry but can you spell out your conclusion?

I wasn't aiming for a conclusion. There appears to be at least two independent mechanisms for injecting debug symbols into an otherwise non-debug macOS executable. This was new to me, and seemed worth sharing in the thread's context.

does that mean that i do NOT need to set this env var at all?

Maybe. Try it and let us know if it continues to work. It might depend on the build configuration for Qt and any other frameworks in use.

[davecotter]

well, i AM only talking about my debug app. definitely not the release app.

and i HAVE already tried debugging without setting that env var, and i am able to step through the Qt sources. so there you go.