Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[xbmc][fix] Fix on demand dll loading to point to the correct files #10155

Merged
merged 1 commit into from Jul 22, 2016

Conversation

@Paxxi
Copy link
Member

commented Jul 22, 2016

I had obviously missed these causing some issues.

@MartijnKaijser

This comment has been minimized.

Copy link
Member

commented Jul 22, 2016

Installer needs adjustment as well regarding copying of files?

@Paxxi

This comment has been minimized.

Copy link
Member Author

commented Jul 22, 2016

it should already copy all files into the root or did you change that?

@Paxxi Paxxi force-pushed the Paxxi:dll_loader branch from 8c144ca to e3391ad Jul 22, 2016
@MartijnKaijser MartijnKaijser added this to the Krypton 17.0-alpha3 milestone Jul 22, 2016
@MartijnKaijser

This comment has been minimized.

Copy link
Member

commented Jul 22, 2016

Looks good so can be merged i guess (no jenkins build needed)

@MartijnKaijser MartijnKaijser merged commit db51af4 into xbmc:master Jul 22, 2016
1 of 2 checks passed
1 of 2 checks passed
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@Tolriq

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2016

@Paxxi don't know if caused by this one, but when debugging on Windows when building to a custom path, cpluff.dll is tried to be loaded at the wrong place.

Loading all the rest works and load dlls from the main kodi directory but cpluff.dll seems to be loaded from portable_directory/..

@Paxxi

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2016

@Tolriq could certainly be caused by this, I haven't noticed any issue but then again I don't think I've tested with -p so there might be some weirdness there.

Will investigate and see.

@Tolriq

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2016

@Paxxi ok no in fact it's the xbmcbin globally that point to KODI_HOME even when forcing a working folder.

Migrating KODI_HOME to the working dir solve that issue but seems to cause a lot of others :(

Issue is a mix between portable mode / working directory in debug settings and KODI_HOME.

Maybe this have changed on another PR and there's just need to have some updates of Wiki to reflect how to handle that ?

@Paxxi

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2016

There's been a lot of volatility in this area the last week as one major change led to many things being overlooked and issues popping up all over the place.

Wiki is not updated as no changes are meant to be required by someone opening up the solution and trying to debug. special://xbmcbin is now meant to point to the root folder/working directory as that's where all the dlls end up after running the installer.

To get this working with the dlls in the system folder we play some tricks and add system to the path for dll resolution during debugging. This fails for some files currently it seems and I'll get it sorted sometime this week.

As a workaround just copy cpluff.dll into the root folder and it should work.

@Tolriq

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2016

Ok thanks, that's what I ended up doing. (All the ones from DllPaths_win32.h as curl is also needed and in my case nfs too).

Just for information since maybe I do things wrong and -p is not the solution, but how are we supposed to manage multiple debugging Kodi profiles for different Kodi versions ? (Like when working on different branches to update previous PR / backport)

Edit : To avoid spam : Ok thanks, so will continue -p as this is what I master for the 12 other production Kodi to test the client side ;)

@Paxxi

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2016

-p is perfectly fine for that or script some simple switching of userdata dirs.

@Voyager1

This comment has been minimized.

Copy link
Member

commented Jul 28, 2016

Why don't we simply put all dll's in the xbmc folder instead of xbmc/system, just like it is in the installation target? Having a different structure between development and (install) release is just begging for problems.

@MartijnKaijser

This comment has been minimized.

Copy link
Member

commented Jul 28, 2016

@Voyager1 that likely also means repackaging every dependency again. Move from system/ to root is now done during packaging

@Paxxi Paxxi deleted the Paxxi:dll_loader branch Mar 11, 2017
@Paxxi Paxxi restored the Paxxi:dll_loader branch May 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.