Project

General

Profile

Actions

Emulator Issues #8535

closed

Compilation fails with libusb < 1.0.16 installed

Added by ears.box almost 9 years ago. Updated almost 5 years ago.

Status:
Won't fix
Priority:
Normal
Assignee:
-
Category:
Controls
% Done:

0%

Operating system:
FreeBSD
Issue type:
Bug
Milestone:
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
Yes
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What's the problem? Describe what went wrong in few words.

4.0-6153 fails To Compile In Linux

What did you expect to happen instead?

Should compile...

What steps will reproduce the problem?
[Don't assume we have ever played the game and know any level names. Be as
specific as possible.]

  1. Tried to compile in Linux and failed...

Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have
known issues and bugs, so don't report issues about them and test the
latest Dolphin version first.
Which versions of Dolphin did you test on?

4.0.6112 was the last version I compiled from source and did not encounter any problems.

Does using an older version of Dolphin solve your issue? If yes, which
versions of Dolphin used to work?

4.0.6112 was the last version I compiled...

What are your PC specifications? (including, but not limited to: Operating
System, CPU and GPU)

Slackware 14.1 x86

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)

I'm attaching a file from the terminal ouput of this crash, dolphin.txt

Actions #1

Updated by Armada almost 9 years ago

Looks like it fails on libusb, maybe you still need to install or update it?

Actions #2

Updated by ears.box almost 9 years ago

I have libusb-1.0.9 installed, did the requirements for a different version recently change?

As I mentioned I compiled 4.0.6112, which was against this version of libsub...

This is the configure output from the terminal for 4.0.6153;

-- checking for module 'libusb-1.0'
-- found libusb-1.0, version 1.0.9
-- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so
Using shared LibUSB

And when I looked at previous versions of dolphin, they all show the same configure options for libusb...

So I don't know why previous versions are working and this isn't something has changed in dolphin source...

Actions #3

Updated by mathieui almost 9 years ago

Okay, so here is the gist of the issue: I started using libusb hotplug events in 6138, which are only supported with the libusb from http://libusb.info/ (ex-libusbx, from what I gather) and not with the libusb from http://libusb.org/, which appears to be the former. It previously didn't matter because we only used a set of features available on both, but not anymore.

I am not sure how to proceed from here, as I don't think we can differentiate between both (libusb-x actively tries to replaces the original one, and it does e.g. in archlinux).

The obvious quick fix for your build is to disable libusb for the time being, but to solve it permanently I may have to remove the use of the hotplug stuff and fall back to polling every X seconds all the time.

Actions #4

Updated by ears.box almost 9 years ago

I'm lost here, I thought the line; 'Using shared LibUSB', meant it was using a version that came with dolphin?

If there seems to now be a problem, why not just include a version with dolphin, seems simple enough?

I see also that the libusb-1.0.9 that is installed is from libusb.org

Actions #5

Updated by mathieui almost 9 years ago

“Using shared libusb” means that dolphin is using the system library. We do include libusb(-x) with dolphin, but it is currently only used on windows systems; using it with our linux/osx builds will require writing a cmake build script for it.

Actions #6

Updated by ears.box almost 9 years ago

Sounds good, I hope this will get done, and please let me know and I can test it out...

If all you're doing it simply having dolphin compile against it, instead of having it installed, shouldn't take to long to write it...

thanks

Actions #7

Updated by ears.box almost 9 years ago

Slackware's 'Current' development version has 1.0.19 from libusb.info

So they've ditched the version from .org

Now I just hope upgrading to this new version isn't going to break anything...

But at lease for now this is working, dolphin compiled ok.

I'd rather not mess with upgrading libusb, so I hope a shared version that comes with dolphin can have it compiled against it, UNLESS it does need to have libusb installed into the system...

Actions #8

Updated by JMC4789 almost 9 years ago

  • Milestone set to Current
Actions #9

Updated by flacs almost 9 years ago

  • Status changed from New to Accepted
  • Milestone deleted (Current)
  • Regression set to Yes
  • Priority set to Normal
  • Category set to controls
  • Easy set to Yes
  • Operating system FreeBSD added
  • Operating system deleted (OS X)

Removing Milestone-Current because there is an easy workaround: upgrade libusb to 1.0.16 or newer. Ubuntu LTS, which we normally use as a reference for which outdated library versions to support, has libusb 1.0.17.

A good fix should simplify the FindLibUSB.cmake file (cf. https://github.com/Tilka/dolphin/commit/5c015a59778b1020933e4ca3827401ec221dc76f), add a version check, and fall back to Externals/.

You can check the libusb version using pkg_check_modules(), not sure if that's available on OS X. If not, add a check_cxx_source_compiles() with something like:

#include
#if LIBUSB_API_VERSION < 0x01000102
#error libusb too old
#endif

Actions #10

Updated by ears.box almost 9 years ago

As I mentioned I did upgrade 1.0.19 from libusb.info and it's working fine.... :)

Actions #11

Updated by leoetlino almost 5 years ago

  • Status changed from Accepted to Won't fix

I think it's reasonable to require >= 1.0.16 nowadays.

Actions

Also available in: Atom PDF