Currently a lot of directories is installed in /usr/share in a format: /usr/share/oprofile/<ARCH>/...
Fixed in oprofile-1.2.0_pre20161027.
Please consider reverting this. Including "alien" arches is not exactly a problem, since stuff not applicable to the machine will not be used. Worse, still, is that the "arches" are not really "arches" as you have thought. For instance, the "i386" arch is also applicable and needed for x86_64 Intel processors. "i386" in this context refers to "Intel", while "x86_64" refers to "AMD". Upstream named this very unfortunately. The end result is that currently oprofile will not work on Intel processors.
(In reply to Mihai Moldovan from comment #2) > Including "alien" arches is not exactly a problem, since stuff not > applicable to the machine will not be used. As I understood the problem is the disk and inode space. May be the case on embedded systems, tight containers and so on. > Worse, still, is that the "arches" are not really "arches" as you have > thought. For instance, the "i386" arch is also applicable and needed for > x86_64 Intel processors. "i386" in this context refers to "Intel", while > "x86_64" refers to "AMD". Upstream named this very unfortunately. > > The end result is that currently oprofile will not work on Intel processors. Hm... definitely not on all Intel processors, since I tested this code on 64-bit Core2Duo E7500 before committing. This issue was my concern before committing the filtering, but apparently my testing was not sufficient. Just curious what is your CPU? Anyway, the change is reverted in oprofile-1.2.0-r1. Please for any new issues open a new bug. It is easy to miss a comment on a closed bug.
(In reply to Andrew Savchenko from comment #3) > (In reply to Mihai Moldovan from comment #2) > > Including "alien" arches is not exactly a problem, since stuff not > > applicable to the machine will not be used. > > As I understood the problem is the disk and inode space. May be the case on > embedded systems, tight containers and so on. Yeah, that makes sense. One can save about 3 MB of disk space and a few inodes if not installing these files. Probably useful on constraint systems. > Hm... definitely not on all Intel processors, since I tested this code on > 64-bit Core2Duo E7500 before committing. This issue was my concern before > committing the filtering, but apparently my testing was not sufficient. Just > curious what is your CPU? A pretty recent Intel i7-7700k (Kaby Lake) CPU, which seems to require timings from the i386/skylake directory - otherwise oprofile won't work. I wonder what oprofile is loading for your CPU. Maybe x86-64/generic. If you're interested, try to strace it to find that out. ----- ionic@apgunner~/src/x2go/libssh-git(git)-[master] % sudo operf --pid 17484 Password: oprofile: could not open unit mask description file /usr/share/oprofile//i386/skylake/unit_masks Unable to find info for event cpu_clk_unhalted ----- > Anyway, the change is reverted in oprofile-1.2.0-r1. Please for any new > issues open a new bug. It is easy to miss a comment on a closed bug. Thanks. I pondered creating a new bug report, but thought that it's (logically) belonging to this, already fixed one. Will be more liberal with new bug reports in the future.
