search

supermerill / SuperSlicer

G-code generator for 3D printers (Prusa, Voron, Creality, etc.)
4.13k stars 520 forks source link

Build error in 2.3.56.0: Inherited from PrusaSlicer - wxWidgets #1189

Open TheAndr0id opened 3 years ago

TheAndr0id commented 3 years ago

I'm not following the template since this is a report of a bug from PrusaSlicer that has been addressed, but for some odd reason hasn't been added to the 2.3.x code base. The bug report is here:

https://github.com/prusa3d/PrusaSlicer/issues/6160

The gist is they added support for media controls in wxWidgets, but wxWidgets is looking for one of the gstreamer include files in the wrong directories. Their fix is to add -DwxUSE_MEDIACTRL=OFF into the wxWidgets cmake file to turn off the media controls. While it doesn't address the core issue of looking in the wrong place for gstreamer includes, it does fix the build since (I guess) there's no reason for the media controls...

The fix can be seen here:

https://github.com/prusa3d/PrusaSlicer/blob/0b16ffaa0772291289607daf31b794ef171fd502/deps/wxWidgets/wxWidgets.cmake#L23

The reason this fix hasn't been included in the 2.3.x code? Um, "Because"?

supermerill commented 3 years ago

Maybe because i haven't merged yet with prusa 2.3.1, only with 2.3.0?

edit: yes, this commit is from march.

I'll merge with 2.3.1 after I get a stable release.

TheAndr0id commented 3 years ago

It won't help. The issue is still in 2.3.1, they didn't tag the fix for the 2.3.x branch. I reopened the issue since 2.3.1 still had the build problem.

supermerill commented 3 years ago

So you ask for a git cherry pick of this commit?

TheAndr0id commented 3 years ago

II'm sorry if my response came off as hostile, that was not my intent. I was just wanting to report you were inheriting an error from PrusaSlicer 2.3.x. This fix should have gone into 2.3.1 but didn't and is being held for 2.4.x I guess.

This error results in an unbuildable source bundle under most Linux distributions, and unless you do a LOT of digging to figure out what is wrong it's extremely frustrating. A hack fix is to just create a symbolic link between the correct location for the include files and where the cmake search looks for them. Something like this:

ln -s /usr/lib64/gstreamer-1.0/include/gst/gstconfig.h  /usr/include/gstreamer-1.0/gst/gstconfig.h

While this works, it will break other OS updates and installs. Not a good solution. The solution provided in the commit works and since the media controls are extra code which shouldn't be in the final binary, it makes sense to remove them.

As for cherry picking git commits, I can totally see your point, but since the current version doesn't work maybe the cherry pick is the right answer? (It will be up to date when you merge 2.4... :P )

(and if you like this issue/ticket, you're gonna LOVE my next one... :D )

supermerill commented 3 years ago

I'm sorry if my response came off as hostile

no worry, it's not. If you think I'm rude, I'm sorry it's not the intent. It's just that I'm not a native English speaker and so I try to be concise.

On my side, I spent sometimes more time maintaining compatibility over os I don't use than fixing bugs or adding features. I build for ubuntu and I don't see any problem here. I can't test & find a solution for other distribution, I don't have enough time for that. I barely have enough time to read all issues sometimes. If you have a fix for your distribution that doesn't break the supported os (win, macos, ubuntu, maybe raspi in the future), I can merge your pull request. If you don't know how to make a pull request, I can help you.

TheAndr0id commented 3 years ago

Fair enough. In this case the fix has already been done and is in the Prusa git repo.

The reason you probably aren't having the issue under Ubuntu is they install all the 32bit compatibility libraries and headers. Because of this when tools just look in /usr/lib they find what they are looking for and it works. In my case my distro (Slackware x64) is strict 64bit and the libraries are under /usr/lib64 and there are no cross links for any 32bit libraries or headers.

Now the root cause of this problem is the wxWidgets maintainers have a bug in their cmake search scripts that aren't using pkg-config correctly. They look first, find the base directory and assume the headers are also there because on a 32 bit/compatibility environment they are. Under a strict 64bit environment they aren't. If they had just used the standard pkg-config tool to pull the info everything would be fine.

Turning off the media controls removes the need for the extra include directory to find the header files which live in a different location on a 64bit only system.