Jump to content

  • Log in with Facebook Log in with Twitter Log In with Google      Sign In   
  • Create Account

winegcc / clang 5.1


  • Please log in to reply
20 replies to this topic

#1 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 14 April 2014 - 03:58 AM

Hi,

My name is Tres and I'm reaching out from the LMMS project.  I recently took it upon myself to port the QT/C/C++/wineg++ free music studio software from Linux to OSX and it has been going fairly well, but I am having some issues getting some Wine stuff working and I think this might be the right community for these questions.  I hope they are well received!

Basically I've ironed out many of the build errors except a few including this one, which seems to be pretty specific to Clang and how it builds Windows executable with the winegcc wrapper.  Has anyone here had to do something like this? :)

Our existing port was done using help from the MacPorts team and all fixes have been commited to upstream stable on GitHub.  Details here:  https://github.com/tresf/lmms/wiki/Compiling-lmms-OSX

The winegcc issue arises after enabling VST support in our CMake script, which triggers it to compile an OSX-Wine wrapper.  This can be enabled by changing this line to "ON' prior to building.  The error log I'm receiving has been posted below, which seems to complain about some specific Microsoft headers that don't seem to be provided with any version of Wine I've found.  Is my configuration wrong?  Is my MacPorts version of Wine causing these issues?  Does Clang think I'm building this on a Windows platform?  I've done a lot of research, to no avail. :)

Any help, including moral support are greatly appreciated!

My Mac OS X Version:
10.9

My Mac Model, GPU & CPU:
VM

Error Log(s):
[ 86%] Generating RemoteVstPlugin
cd /Users/tres/lmms/build/plugins/VstBase && wineg++ -I"/Users/tres/lmms/build" -I"/Users/tres/lmms/include" -I"/usr/local/include/wine/windows" -I"/usr/local/include" -I/usr/include/wine/windows "/Users/tres/lmms/plugins/VstBase/RemoteVstPlugin.cpp" -mwindows -lpthread -o RemoteVstPlugin
In file included from /Users/tres/lmms/plugins/VstBase/RemoteVstPlugin.cpp:35:
In file included from /Users/tres/lmms/include/RemotePlugin.h:29:
In file included from /Users/tres/lmms/include/MidiEvent.h:28:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/cstdlib:88:
/Users/tres/lmms/include/support/win32/locale_win32.h:23:10: fatal error:
	  'crtdefs.h' file not found
#include <crtdefs.h>
		 ^
1 error generated.
winegcc: /usr/bin/clang++ failed
make[2]: *** [plugins/VstBase/RemoteVstPlugin] Error 2
make[1]: *** [plugins/VstBase/CMakeFiles/VstBase.dir/all] Error 2
make: *** [all] Error 2

Posted Image

#2 Zorg

Zorg

    Professional Member

  • Members
  • PipPipPipPip
  • 147 posts
  • LocationSpace
  • Graphics Card:I don't know.
  • Operating System:Other OS/Not specified
  • I like to play:Arcade, Side Scrollers

Posted 14 April 2014 - 12:29 PM

Just have to ask. Why are you using Wine? Isn't Qt a cross platform framework?

#3 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 14 April 2014 - 08:11 PM

View PostZorg, on 14 April 2014 - 12:29 PM, said:

Just have to ask. Why are you using Wine? Isn't Qt a cross platform framework?

Yes, we're running QT natively (you can try a pre-release DMG bundled copy of the software by clicking here, no VST support of course)

We're only using Wine for one very small module of our code, an optional plugin called "Vestige".  This plugin offers VST instrument support, which has historically been much more prominent on Windows.  Wine provides this functionality on Linux because winegcc can compile the native C++ to Wine C++ wrapper.  This is the step I'm suck on, Clang compiling the Wine wrapper.  I'm hoping there is some experience on this site with such an obscure combination of technologies... :)

A picture is 1000 words, right?  For example, here's a GTG Synths free plugin called GTG DPC 3.  It's just a drum pad.  What you're looking at though is a Windows VST drum pack running on Ubuntu which can be used to make music via a native QT application (Yes, a DLL loaded via GNU C++ by using a Wine wrapper!)

These VST plugins are very popular for composing music so supporting them ranks fairly high on our priorities and in turn is well received by our community of musicians.

We'd like to expand our community even more and having an Apple build with similar feature set (we hope) will encourage that! :)

[Old screenshot of 0.4.14-rc1 running a Windows VST drum pack]
Posted Image

For some reason Clang errors on compile and I'm sure it's a configuration issue, but I'm having a hard time finding someone who's tried this before on OSX. :)

-Tres

#4 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 16 April 2014 - 12:17 AM

You're likely aware of it, but Wine for Mac OS X only supports Core Audio...I see lots of Alsa, Pulse and Jack in the lines that you linked...all of which I think are supported on Linux...but Mac only allows the transition from the core audio driver.

a member here that goes by Drakulix may be able to help you out. He was developing CiderX here and helping out alot with iLoL

#5 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 16 April 2014 - 12:54 AM

View PostDankoB, on 16 April 2014 - 12:17 AM, said:

I see lots of Alsa, Pulse and Jack in the lines that you linked...all of which I think are supported on Linux...but Mac only allows the transition from the core audio driver.

You mean these lines? :)

IF(LMMS_BUILD_APPLE)
   SET(WANT_ALSA OFF)
   SET(WANT_PULSEAUDIO OFF)

Yes, we're using CoreAudio for the main C++ code, but I'm not entirely sure how audio's handled within the winegcc code.

Quote

Drakulix may be able to help you out


Great, what's the best way to contact Drakulix?

-Tres

#6 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 18 April 2014 - 10:26 AM

Yeah...those were the lines...I was also looking at the WIN32 build.

You could send him a private message here or e-mail...  http://portingteam.com/user/175-drakulix/  Although he's not quite as active as he was before he does come around once in awhile. Here's hoping you get this all figured out!

#7 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 18 April 2014 - 01:52 PM

View PostDankoB, on 18 April 2014 - 10:26 AM, said:

Yeah...those were the lines...I was also looking at the WIN32 build.

You could send him a private message here or e-mail...  http://portingteam.com/user/175-drakulix/  Although he's not quite as active as he was before he does come around once in awhile. Here's hoping you get this all figured out!

PMed, thank you!

#8 Kama.Stein

Kama.Stein

    Champion Member

  • Donators
  • 646 posts
  • LocationCyberspace
  • Graphics Card:NVIDIA GTX 680MX 2GB
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:First Person Shooters, Arcade Games, Adventure Games, Platformers, Puzzlers

Posted 19 April 2014 - 06:07 AM

IF(LMMS_BUILD_APPLE)
   SET(WANT_ALSA OFF)
   SET(WANT_PULSEAUDIO OFF)
Correct me if I'm wrong but those lines seem to indicate if you are building for Apple then turn those things OFF. So no, it's not trying to use Alsa or Pulsaudio on Mac. Futhermore I'd say lines like those are good to have to be sure they aren't attempted to be used on Mac. I mean I'm not a programmer but it seems fairly obvious to me.



seem to indicate
--Kama
It's funny how the colors of the real world only seem really real when you viddy them on the screen.
-- Alex Delarge, A Clockwork Orange
Late 2012 27 inch iMac, Core i7 Quad 3.4GHz, 16GB RAM, Nvidia GeForce GTX 680MX 2GB, 3TB Hard Drive

#9 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 19 April 2014 - 08:47 PM

View PostTetsu, on 19 April 2014 - 06:07 AM, said:

Correct me if I'm wrong but those lines seem to indicate if you are building for Apple then turn those things OFF. So no, it's not trying to use Alsa or Pulsaudio on Mac. Futhermore I'd say lines like those are good to have to be sure they aren't attempted to be used on Mac. I mean I'm not a programmer but it seems fairly obvious to me.

seem to indicate

Yes you are correct.  I assume you're responding to @DankoB's message.

I've crawled the internet and back again and it seems there are only a handful of documented winegcc + OSX threads out there.  One I found was here on the portingteam site, so I'm optimistic someone here may be able to help? :)

#10 Drakulix

Drakulix

    Old nearly vanished Member

  • Members
  • 1903 posts
  • LocationGermany
  • Graphics Card:nVidia GeForce 650M 1GB
  • Operating System:OS X 10.9 (Mavericks)
  • I like to play:FPS, Action, Minecraft, Skyrim, Strategy, rare Racing

Posted 20 April 2014 - 06:15 PM

Hey there.

Is it absolutely necessary for you, that it build correctly with clang?
clang and XCode are using some wired quirks and might break the winegcc cross-compiler.

I would suggest, that you use homebrew to install a recent gcc version (e.g. gcc-4.8). and then do the following before building via terminal:
export CC=gcc-4.8
export OBJC=gcc-4.8
export CPP = cpp-4.8
export CXX = c++-4.8
export LD = gcc-4.8

Posted Image

#11 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 21 April 2014 - 04:06 AM

View PostDrakulix, on 20 April 2014 - 06:15 PM, said:

Is it absolutely necessary for you, that it build correctly with clang?
No, there is nothing forcing us to use clang.  I chose it for the normal reason... It's default.  I also have heard fantastic things about it in terms of performance and efficiency and our developers have been very accommodating to get our own code up to standard.

However, it has also caused a lot of grief.  Some 3rd party components we use fail to build due to it's strictness and have since been left unmaintained by their authors.  Switching to GCC would certainly be beneficial from a compatibility standpoint, although I'm not savvy of the intrinsic benefits of one over the other.

Quote

clang and XCode are using some wired quirks and might break the winegcc cross-compiler.

I would suggest, that you use homebrew to install a recent gcc version (e.g. gcc-4.8). and then do the following before building via terminal:
export CC=gcc-4.8
export OBJC=gcc-4.8
export CPP = cpp-4.8
export CXX = c++-4.8
export LD = gcc-4.8
Great.  MacPorts seems to offer that, so I can try that right away.  Thank you!! :)

#12 Drakulix

Drakulix

    Old nearly vanished Member

  • Members
  • 1903 posts
  • LocationGermany
  • Graphics Card:nVidia GeForce 650M 1GB
  • Operating System:OS X 10.9 (Mavericks)
  • I like to play:FPS, Action, Minecraft, Skyrim, Strategy, rare Racing

Posted 21 April 2014 - 08:05 AM

I would strongly discourage using macporfs.
homebrew does the same job way better.
MacPorts installs all libraries and binaries directly into /usr/local, confusing a lot make-based installers, that do assume your mac os comes with the (mostly outdated) default libraries. Homebrew however just installs a bunch of symlinks, that can be temporary removed. Overall it's much cleaner.

You are right, that clang is a fantastic compiler, but wine (and all components belonging to wine) is one of these projects, where clang is simply not working correctly. the wine devs have build up some indirect dependencies to gcc (probably not intentionally).
Posted Image

#13 ryandesign

ryandesign

    Lurker

  • Members
  • 3 posts
  • Graphics Card:Intel HD Graphics 4000
  • Operating System:OS X 10.9 (Mavericks)

Posted 21 April 2014 - 09:18 AM

Hello, I am a manager of the MacPorts project. Tresf referred me to this thread, and I created an account on this site in order to respond to your message:

View PostDrakulix, on 21 April 2014 - 08:05 AM, said:

I would strongly discourage using macporfs.
homebrew does the same job way better.
MacPorts installs all libraries and binaries directly into /usr/local, confusing a lot make-based installers, that do assume your mac os comes with the (mostly outdated) default libraries. Homebrew however just installs a bunch of symlinks, that can be temporary removed. Overall it's much cleaner.

You are right, that clang is a fantastic compiler, but wine (and all components belonging to wine) is one of these projects, where clang is simply not working correctly. the wine devs have build up some indirect dependencies to gcc (probably not intentionally).

It should not surprise you that I would strongly discourage anyone from using Homebrew, because MacPorts does the same job way better. In fact that's not quite true. I try not to discourage people from using Homebrew, or Windows, even if I prefer MacPorts and OS X. People should be free to use whatever tools they prefer to get the job done, even if they are not the tools I prefer to use. I just wish people would refrain from publicly and emphatically disparaging something that I've spent hours of time each day for many years improving, especially when the disparagement is inaccurate.

MacPorts does not install into /usr/local. It never has, for precisely the reasons you state: it would confuse a lot of make-based installers, because compilers default to looking for dependencies in /usr/local. MacPorts defaults to the prefix /opt/local. This can be changed at configure time if the user really wants to, however we specifically prohibit users from selecting the prefix /usr/local. We talk about this in our FAQ: https://trac.macport...#defaultprefix; https://trac.macport...ki/FAQ#usrlocal .

Homebrew on the other hand, as I understand it, does install into /usr/local by default, thus causing the problems you mention.

I’m not aware of any general problems that the current versions of Wine have with Clang. Wine used to not build with Clang, but that was fixed several versions ago. As for winegcc, I have not used it. It may have Clang-related problems I don't know about. If so, they should be fixed, because Clang is the future on OS X, and the future is now. Clang is the only compiler included in Xcode 5 and later. Apple has been moving towards Clang for years; trying to fight that is a losing battle. Support Clang, or forfeit OS X compatibility.

I'm not certain what "wired quirks" of Clang and Xcode you're referring to. Xcode isn't really related to compiling software on the command line, which is what we're talking about here. And Clang, well, it does things differently from GCC, but different does not mean wrong. Usually, when Clang fails to build something, it provides extremely detailed error messages that more often than not point out an actual mistake in the original source code that the developer is grateful to fix.

If you are only trying to compile C code, then yes, you can install GCC using MacPorts or Homebrew or any other method you desire. That's not optimal, because installing another compiler takes time and disk space, but it is possible. But if the code you’re trying to compile includes C++ code, and you are on OS X 10.9 Mavericks or later, and you either need to link with other C++ libraries, or other C++ software needs to link with you, then you must use Clang; using LLVM-GCC or GCC will simply not work, because as of OS X 10.9 Mavericks, OS X uses libc++, whereas other compilers use libstdc++, and you cannot mix the two different C++ runtimes in the same address space. See https://trac.macport...wiki/FAQ#libcpp .

#14 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 21 April 2014 - 03:15 PM

View PostDrakulix, on 21 April 2014 - 08:05 AM, said:

MacPorts installs all libraries and binaries directly into /usr/local, confusing a lot make-based installers

I've read this so many times on the internet that I almost believed it and ALMOST looked right past MacPorts.  Even our project manager threw big red flags warning me of this, but it's simply not true.  If MacPorts has issues, the "/usr/local" rumor isn't one of it's issues. :)  Arstechnica helped me understand here

I'm sure there're some compelling reasons for one over the other, but LMMS has no preference (yet) so as long as the compiler builds the .DYLIB's and .SO's properly and our DMG-app script links and bundles them, and the application launches and works well, then the chosen tool did it's job well.

The only reason the LMMS project chose MacPorts to begin with is the generous help from people like RyanDesigns over the years.  90% of the work was already done for us, thus MacPorts was chosen out of the tremendous efficiency it offered our project.  We all know that these quirks can take (and have taken) weeks or months to sort out and meanwhile the core LMMS developers have little or no incentive to help (selling the idea of proprietary OS compatibility to FOSS advocates is an uphill battle).  Luckily now the project is accepting these patches upstream so the build process should get easier on OSX with time.  Starting with 1.0.0 our LMMS core code builds with Clang, but we're still fighting some of the plugins.

So to be clear, we (LMMS) don't have a preference to one porting framework versus the other because we compile all of our OSX code in a sandboxed VM, and we use VM snapshots to protect from system instabilities.  We could switch to Homebrew today if it helps with this or other issues, but I've seen no compelling reason to switch as of yet.

Which brings us here... So... Back to the topic at hand... if winegcc will likely cause issues when used with gcc then are we left asking the llvm guys for help?

Thanks to all parties for taking the time to both read and respond. :)  I don't mind conflict so as long as it brings us closer to resolve.

-Tres

#15 Drakulix

Drakulix

    Old nearly vanished Member

  • Members
  • 1903 posts
  • LocationGermany
  • Graphics Card:nVidia GeForce 650M 1GB
  • Operating System:OS X 10.9 (Mavericks)
  • I like to play:FPS, Action, Minecraft, Skyrim, Strategy, rare Racing

Posted 21 April 2014 - 04:20 PM

View Postryandesign, on 21 April 2014 - 09:18 AM, said:

Hello, I am a manager of the MacPorts project. Tresf referred me to this thread, and I created an account on this site in order to respond to your message:

It should not surprise you that I would strongly discourage anyone from using Homebrew, because MacPorts does the same job way better. In fact that's not quite true. I try not to discourage people from using Homebrew, or Windows, even if I prefer MacPorts and OS X. People should be free to use whatever tools they prefer to get the job done, even if they are not the tools I prefer to use. I just wish people would refrain from publicly and emphatically disparaging something that I've spent hours of time each day for many years improving, especially when the disparagement is inaccurate.

First of all, I am sorry, that this statement is not very fair towards MacPorts and I should clarify a bit, what my particular problem is with it.
To be honest it has been quite a while since I was using MacPorts and it might be, that my feedback is simply outdated and MacPorts has improved a lot. Also I totally understand that maintaining something that scale is very difficult, it is just my personal user experience. I have no clue, which of these projects have the better technical implementation, but in the end that does not matter, because I am just using, what is working better for me.

View Postryandesign, on 21 April 2014 - 09:18 AM, said:

MacPorts does not install into /usr/local. It never has, for precisely the reasons you state: it would confuse a lot of make-based installers, because compilers default to looking for dependencies in /usr/local. MacPorts defaults to the prefix /opt/local. This can be changed at configure time if the user really wants to, however we specifically prohibit users from selecting the prefix /usr/local. We talk about this in our FAQ: https://trac.macport...#defaultprefix; https://trac.macport...ki/FAQ#usrlocal .

Homebrew on the other hand, as I understand it, does install into /usr/local by default, thus causing the problems you mention.
Obviously you are right. However still Homebrew feels much cleaner for me. When I was using MacPorts, I got the feeling, that more packages were broken then working correctly and it was a huge mess cleaning up broken and unused packages. I often removed my whole /opt/local folder or did even reinstall my Mac OS System to fix everything again, while Homebrew was just working the very first day for me.
The best thing about Homebrew is, that everything gets symlinked. I can simply unlink every installed package without actually removing it, when it is causing problems.
(You could argue, that for MacPorts you only need to remove /opt/local from your path, but that removes everything temporarily and not just the library, that was causing problems.) And I can even install other third-party libraries and binaries into the homebrew folder and link and unlink them, when needed, even if homebrew does not offer to install that particular library for you. I have a whole mingw-compiler suite set up with homebrew and it really helps me updating parts of it, without having the feeling of modifying my whole system and breaking my /usr prefix. I have no idea, how to describe it, but MacPorts nearly felt like installing a complete gentoo prefix into my mac os system (I was shocked when I found out, that this is actually possible: https://www.gentoo.o...too-alt/prefix/ ). I like systems, that I do understand and can try to fix for my self. Everything in that scale, that manages to provide open-source and easily understandable code, is pure magic to me. Creating and fixing existing homebrew-recipes is easy (at least for me) and speaks for it's simplicity. With MacPorts however I have most times no other chance then filling a bug request and wait some days.


View Postryandesign, on 21 April 2014 - 09:18 AM, said:

I’m not aware of any general problems that the current versions of Wine have with Clang. Wine used to not build with Clang, but that was fixed several versions ago. As for winegcc, I have not used it. It may have Clang-related problems I don't know about. If so, they should be fixed, because Clang is the future on OS X, and the future is now. Clang is the only compiler included in Xcode 5 and later. Apple has been moving towards Clang for years; trying to fight that is a losing battle. Support Clang, or forfeit OS X compatibility.
It might be, that the current clang version is building wine just fine. The last time I tried it totally broke and the resulting wine executable just crashed on starting nearly any windows binary, overall it was very unstable (that happened on a totally clean system).


View Postryandesign, on 21 April 2014 - 09:18 AM, said:

I'm not certain what "wired quirks" of Clang and Xcode you're referring to. Xcode isn't really related to compiling software on the command line, which is what we're talking about here. And Clang, well, it does things differently from GCC, but different does not mean wrong. Usually, when Clang fails to build something, it provides extremely detailed error messages that more often than not point out an actual mistake in the original source code that the developer is grateful to fix.
I do not want to discourage anyone from using clang. I love it's verbosity and you do not need to tell an ObjC developer, how awesome clang is. I have not enough knowledge about compilers in general to judge it technically, although I only heard positive things about it, but it's supported features, like the "new" ObjC fragile-abi and the C blocks extension (libdispatch is awesome) are very useful and well designed. It's just my personal experience with clang + wine, that did lead me to that recommendation. I am still not sold on Apple's decision to drop the gcc completely in Xcode 5, (although you can add the old gcc plugin just fine, if you really wanna use it,) but at least it is pushing clang's popularity lately.


View Postryandesign, on 21 April 2014 - 09:18 AM, said:

If you are only trying to compile C code, then yes, you can install GCC using MacPorts or Homebrew or any other method you desire. That's not optimal, because installing another compiler takes time and disk space, but it is possible. But if the code you’re trying to compile includes C++ code, and you are on OS X 10.9 Mavericks or later, and you either need to link with other C++ libraries, or other C++ software needs to link with you, then you must use Clang; using LLVM-GCC or GCC will simply not work, because as of OS X 10.9 Mavericks, OS X uses libc++, whereas other compilers use libstdc++, and you cannot mix the two different C++ runtimes in the same address space. See https://trac.macport...wiki/FAQ#libcpp .
That's actually very interesting. I did not know this, so thanks for pointing that out.



View Posttresf, on 21 April 2014 - 03:15 PM, said:

Which brings us here... So... Back to the topic at hand... if winegcc will likely cause issues when used with gcc then are we left asking the llvm guys for help?

Thanks to all parties for taking the time to both read and respond. :)  I don't mind conflict so as long as it brings us closer to resolve.

-Tres

I actually cannot tell you, because I did not work with winegcc yet.
But I believe that it is called winegcc and not winecc for a reason, it likely was only tested correctly with the gcc. Also using clang for windows code works, but is quite experimental currently (at least when using clang with msys/mingw on windows). Also clang's support for windows executables is not full featured. It currently uses the gcc as linker, because clang's linker is not working correctly on windows (resulting in no C-blocks or other objc-runtime-support other then the gnu and gnustep runtime on windows for example). So even if it should work, it is quite likely, that it is simply not supported or well tested and that you should give the gcc a try, if you are interested in finishing you project soon. However I bet the llvm guys would be interested into some well documented error reports.


EDIT:
Offtopic: I just wanted to point out, how awesome this community still is after so many years. I barely visit this site anymore, since many games are released on mac anyway, but I learned a lot as part of this community and that I still get pm's about issues like this, shows how much respect many people around here still have. And that I just get in contact with the manager of MacPorts so easily like this, means a lot.

Actually I must apologize for my last posts towards tresf, as I was a bit rushed, when writing those. Statements like "Xcode and clang are using some wired quirks" are just plain wrong. I was just writing with the attitude, that I need to make clear, that this combination is not well tested and should be avoided for producing as it is quite new. And when you try to tell somebody, that the new technology is not compiling something the old one managed to compile with ease, but that he should blame the code, instead of the new technology, you usually get to see confused faces. I really appreciate the technically level we reached now in this discussion and apologize for any inaccurate or even wrong explanations.

Edited by Drakulix, 21 April 2014 - 04:31 PM.

Posted Image

#16 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 22 April 2014 - 04:13 AM

This is likely not relevant to the topic at hand, but this snippet is on the http://wiki.winehq.o...HQ project page:

Quote

Note that the default compiler is llvm-gcc, which won't work for wine. Clang can compile wine, but it miscompiles winemac.drv (and potentially other stuff). gcc-apple-4.2 is known to work.


So... shot in the dark but is there a chance this is related to the compile settings in the winports version of Wine?

Or, is there a registry hack I can install to trick winegcc into thinking it doesn't need Visual Studio type header files? :)

#17 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 30 April 2014 - 05:34 PM

Ok, I just had an idea... I'm compiling using VirtualBox.  When I issue the command
uname -p
, it returns
i386
.

Is there a chance wingcc thinks I'm on 32-bit, hence looking for the 32-bit headers (i.e. locale_win32.h)

Note that CMake does a great job of doing platform detection as i686.  But this misreported architecture type... is there a chance the winegcc wrapper uses this and is breaking the compilation requirements?  Or am I just over-thinking this?

#18 ryandesign

ryandesign

    Lurker

  • Members
  • 3 posts
  • Graphics Card:Intel HD Graphics 4000
  • Operating System:OS X 10.9 (Mavericks)

Posted 30 April 2014 - 08:19 PM

View Posttresf, on 22 April 2014 - 04:13 AM, said:

This is likely not relevant to the topic at hand, but this snippet is on the http://wiki.winehq.o...HQ project page:

Quote

Note that the default compiler is llvm-gcc, which won't work for wine. Clang can compile wine, but it miscompiles winemac.drv (and potentially other stuff). gcc-apple-4.2 is known to work.

As they say on Wikipedia, "citation needed". Wine used to not compile with clang, then they fixed it, so in MacPorts I removed the blacklisting for clang, and I haven't had any reports now of it not compiling. If other users are still experiencing problems compiling Wine with clang, there should be a ticket in the Wine bug tracker about that. I found 2 open ones, but neither has been modified in over 2 years.

View Posttresf, on 30 April 2014 - 05:34 PM, said:

Ok, I just had an idea... I'm compiling using VirtualBox.  When I issue the command
uname -p
, it returns
i386
.

Is there a chance wingcc thinks I'm on 32-bit, hence looking for the 32-bit headers (i.e. locale_win32.h)

Note that CMake does a great job of doing platform detection as i686.  But this misreported architecture type... is there a chance the winegcc wrapper uses this and is breaking the compilation requirements?  Or am I just over-thinking this?

What do you mean, compiling using VirtualBox? I thought you were compiling using winegcc running on OS X.

As far as I know, it is normal for "uname -p" to return "i386", even on 64-bit Intel Macs. Mine does. If you want a programmatic way to determine if a Mac (running Mac OS X 10.5 or later) is 64-bit capable, you can run "sysctl hw.cpu64bit_capable", which will return "1" or "0".

Wine is always built 32-bit in MacPorts, because it didn't used to be possible to build Wine 64-bit. I see some progress has been made on this, but according to http://wiki.winehq.o...e64ForPackagers that progress is only for Linux at this point. So winegcc will be 32-bit. I don't know what impact, if any, that has on what kind of code winegcc can generate.

#19 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 01 May 2014 - 03:25 AM

Quote

As far as I know, it is normal for "uname -p" to return "i386", even on 64-bit Intel Macs
Yes, I see that now thank you.

Quote

What do you mean, compiling using VirtualBox? I thought you were compiling using winegcc running on OS X.
All of my compilation is done within a separate VM instance of Mavericks.  You are correct, the part I'm inquiring about in this thread is specific to the winegcc compiler.  Conspiring thoughts led me to believe the i386 could be causing issues, but as you've illustrated this is a false alarm.  I just recently read why.  

Sorry for this confusion (and thank you for the reply).

Is there a better community for the WineGCC + Clang questions?  I understand writing native C++ to talk to Wine C++ isn't very common but when I start Googling for the missing header files listed in the original compilation errors I wind up stumbling upon MSVC headers, which don't help the situation much and suggest something is wrong (the LMMS devs don't have this issue on Linux).  Furthermore, most of the internet's searches for winegcc are people compiling Wine itself, whereas I just want to create a sort of MingW compatible VST bridge similar to how the Linux version does.

Perhaps, is there a chance that the headers used in some of the vst_base source code falsely trigger these MSVC headers with Clang?

#20 ryandesign

ryandesign

    Lurker

  • Members
  • 3 posts
  • Graphics Card:Intel HD Graphics 4000
  • Operating System:OS X 10.9 (Mavericks)

Posted 01 May 2014 - 03:47 AM

View Posttresf, on 01 May 2014 - 03:25 AM, said:

All of my compilation is done within a separate VM instance of Mavericks.  You are correct, the part I'm inquiring about in this thread is specific to the winegcc compiler.  Conspiring thoughts led me to believe the i386 could be causing issues, but as you've illustrated this is a false alarm.  I just recently read why.  

That article discusses why certain 64-bit Macs under certain by-now old versions of OS X would still be using the 32-bit kernel, and why that's not a problem. That's true, but it's old information. By now, current Macs under current versions of OS X use the 64-bit kernel, and even in that case, "uname -p" is "i386". "uname -m", however, will be "x86_64"; you can use that to tell what architecture the kernel is, but as the article discusses, the only time you need to care about that is if you're installing kernel extensions.

#21 tresf

tresf

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:Onboard
  • Operating System:OS X 10.9 (Mavericks)

Posted 01 May 2014 - 05:00 AM

Thanks again for the clarification.

I found this article about win32 incorrectly assuming MSVC... Could this be the cause of my grief?

http://lists.cs.uiuc...826/087093.html

If so, what would be protocol to apply this patch (or verify status of it)?

There have been updates to the Command Line tools since I started this project (1.2GB), which I've been putting off for some time now, but perhaps this has been addressed?

-Tres




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users