http://bugs.winehq.org/show_bug.cgi?id=26593
Summary: It is not possible to discover compile options Product: Wine Version: 1.3.16 Platform: x86-64 OS/Version: Linux Status: NEW Keywords: download, source Severity: enhancement Priority: P2 Component: build-env AssignedTo: wine-bugs@winehq.org ReportedBy: kennybobs@o2.co.uk
Unless I'm mistaken, there is no way to figure out what the compile options of a pre-built Wine were.
It would be quite useful for wine --version to display this information, or the About tab in winecfg, but if there was any way at all, even a text file, to figure out what compile options were used it would make it much easier to find compile bugs, or following a custom build to discover what the custom build entailed.
-- I searched for a similar open bug a number of different ways but could not find anything. Apologies if this is a duplicate.
I would have a go of solving this myself, but it would be very simple and almost definitely wrong.
http://bugs.winehq.org/show_bug.cgi?id=26593
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2011-03-30 04:08:19 CDT --- Compile options are usually irrelevant. Do you have a specific use case where it would matter?
http://bugs.winehq.org/show_bug.cgi?id=26593
--- Comment #2 from Ken Sharp kennybobs@o2.co.uk 2011-03-30 04:28:25 CDT --- It would have helped me to diagnose Bug 26591 and Bug 17971, for example. Luckily I had access to the package maintainer, but maybe not everybody would. I've seen other similar bugs, but I cannot recall what they were (probably games!)
winejack doesn't currently build, so in cases such as this where --without-whatever is used, it would be handy to know if/when such builds are packaged.
It would be nice to know which GCC is used to build a package so that one knows if one is using a GCC that should or should not work.
It would be nice to know which optimisations are used during build so that one can decide whether there would could be any improvement for a specific machine (even more useful as the number and types of CPUs being used continues to increase).
Which kernel version it was built against... and so on and so on.
It's "nice to know" what happened to a package before it got to you. Ubuntu, for example, adds all kinds of non-default crap to their packages.
Etcetera, ad infinitum.
http://bugs.winehq.org/show_bug.cgi?id=26593
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2011-03-30 05:12:50 CDT --- That sort of thing belongs in the package then.
http://bugs.winehq.org/show_bug.cgi?id=26593
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #4 from Eric Pouech eric.pouech@orange.fr 2011-03-30 05:16:07 CDT --- actually, you should have this information in the (dwarf) debug information dwarfdump utily should be your friend A+
http://bugs.winehq.org/show_bug.cgi?id=26593
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Dmitry Timoshkov dmitry@codeweavers.com 2011-03-30 06:56:33 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=26593
--- Comment #6 from Ken Sharp kennybobs@o2.co.uk 2011-03-31 03:07:23 CDT --- What package? A make install copies files, it's not asking much that a wine --version tells you what happened during compilation! It would be no more difficult to implement than having it report the version number!
http://bugs.winehq.org/show_bug.cgi?id=26593
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2011-03-31 05:19:24 CDT --- Compiler options can vary for each file, that's why they belong in the file debug info. The configure flags don't tell you anything, if you want to know if a module was compiled just check if it exists. Kernel version is even more irrelevant.
http://bugs.winehq.org/show_bug.cgi?id=26593
--- Comment #8 from Ken Sharp kennybobs@o2.co.uk 2011-03-31 11:08:46 CDT --- So when I'm looking at response speeds for different builds, the configure options are irrelevant? What is relevant then?
Broken kernels can cause compilation madness - not often, granted.
GCC version is very relevant.