I made a simple command line application that declares functions in a dylib. The library is added to the project using a build copy operation. When I build, the application’s .debug folder contains the copied file and all works as expected. Once I was done testing in that CLI, i started building a simple GUI application to use the same library.
I created a build copy step and dragged my dylib to it. The path is black (not red), so it sees it’s there. When I run the program in the debugger, though, no .debug folder is created while the app is running. I’m getting errors that the function was not found so I need to check that the build copy step is working.
I’m seeing this on both Mojave and Big Sur. Is the .debug folder in a different place for GUI applications or something?
Just to clarify - I do see the .debug version of my application appear in the project folder in the GUI app. For the CLI app, a folder called “project-name.debug” is created. The application.debug executable goes in there, and the libraries are copied into the framework subfolder of the project-name.debug folder. But for the GUI, this folder structure doesn’t exist?
It doesn’t matter - even if I choose App Parent Folder or any of the others, no .debug folder is created in the project folder like it is with the CLI version.
Sounds like you’re doing some gymnastics to work around an issue in the wrong way. You shouldn’t need to know where the .debug build is to use a bundled dylib’s functions.
Additionally, yes, it does change depending on the target. Tell us, why do you need to know where the debug folder is?
CopyFiles puts it into the folder your specify, you shouldn’t need to know where on disk that is. Windows, Mac, Linux, Desktop, and Console all build the debug folder differently.
On Desktop macOS, it’s not a folder. It’s Myapp.debug.app
CopyFiles puts it into the folder your specify, you shouldn’t need to know where on disk that is.
Ok, I get that now. No need to tell me I don’t need to know where it is though - I’m getting an error that the function isn’t found. Therefore the first, most logical step in testing that is to make sure the library file is there. I didn’t know it was put inside the package, since I usually make command line apps, where it goes in a folder.
I don’t know what more to say. I even already told you what to expect for Mac Desktop.
Those posts were crossed. we posted at basically the same time. I read your other thread the other day and I have to say if you want people to treat you with respect for the information you offer up, you might want to try doing the same for them. Seriously, there’s no need to be the arrogant programmer dude here.
Update: I should add that it’s complicated to pack a console helper app into a macOS desktop app and have it share resources.
I’m not doing that. Not sure where that came from.
I built a CLI to test a library. Once tested I built a GUI against the same library. Different applications, as I said in my first post.
You should circle back to that thread where you dismissed the dylib pathing issue. That’s your real problem, it needs to be packed for an application bundle and I’d bet it’s not.
What thread is that, and what did I dismiss? do you mean this one? because in that case, the issue turned out not to be the path to the dylib (which was correct, and was tested as suggested using a simple helloworld library), but a configuration problem with the install of the underlying frame grabber drivers. Once that config issue was fixed, everything worked. Or are you talking about something else?
If you need further detail we can draft up a consulting contract, the research behind the answer to this took me a significant amount of time. You could also try to get Xojo to help you as part of the technical support service that’s included with your license.
Just out of curiosity, could you show the Declare code that you are using to access the library?
Is this that?
Declare Function GetBoardCount Lib "libCoaxLinkGrabber.dylib" (byref count as UInt32) as Integer
dim success, count as UInt32
success = GetBoardCount(count)
break
Tim - This is not a matter of me “dismissing” anything. I said right after that, in that same post, that the change the programmer who made the dylib made was fine. This is an application that will live on one machine, ever. It’s not being sold commercially, so I just need it to work, I don’t need a solution that will work for installations on other machines.
It doesn’t even need to be a function that has any parameters:
Declare Function OpenCxpDriver Lib “libCoaxLinkGrabber.dylib” () as Integer
dim driverOpen as integer = OpenCxpDriver()
…fails with “function not found” when called from the GUI app, but the exact same code works from the CLI app. Both are pointing to the same dylib file in the build copy operation, and both are correctly copying the file to the expected locations (inside the app package for the gui, and inside the ,debug folder for the CLI.
That’s totally irrelevant to why it’s not working.
You need to stop acting like you’re not doing anything wrong, your code is not working. I am not being arrogant, I am pointing out where your shortcuts have failed you.
I’ve told you plenty about what the problem is. Threw the terms into Google, and you may find an article that will help. By making this into a personal attack, I rescind my offer to help privately. Good luck with your research.
