Build wine on buster

[ImperatorS79]

And rebuild all wine from 4.0.

[qparis]

If we do this, wine won’t work on stretch any longer. The contrary is not true

[ImperatorS79]

Well, I think any people using wine have or should update to buster (just in term of graphics drivers for example).

[qparis]

Maybe but it won’t always be the case

What is the point for us to do it? Will it have any positive impact?

[ImperatorS79]

Well, it is just the question: "under which debian version do we build wine ?" If it is old stable, that means we will keep building it under stretch for about at least two years, which seems a lot to me considering how fast software and hardware are changing.

If I follow what you just said, we could also decide to build it under jessie, why not ? (until june 2020 end of support). So at least we need to decide of a criterion.

Last but not least, debian stretch libs seems to be unable to launch notepad++. I think it could be good to at least see what it does when we build wine and its runtime on buster.

[qparis]

Old stable is not supported because we had a real good reason (don’t remember which one but it was something about 3rd party libs like vk3d that would require new dependencies to build)

The more the distributions are old, the less likely it is for them to work.

I definitely agree that we should understand what’s happening with n++ though. Libfreetype again maybe?

[ImperatorS79]

It is not libfreetype.

[ImperatorS79]

I just tested by installing libwine-development:i386 on my system (ubuntu 19.10) and notepad++ launched (without runtime). So it really seems that it is a problem in a lib provided by debian stretch. So there is multiple things to try:

• We build on buster a wine version and a runtime to see if it fix the issue.
• We try to find why it does not work with the debian stretch libs (i.e. which lib from the runtime should be installed as a .deb dependency)
• We only put in the runtime the minimal list of lib that we now we need an exact version (exemple libavcodec libavutil) and we install all the other libs from the host distribution.

I always have been in favor of the third option, but I know it will require some work (to identify which libs are needed and because it could be a distribution dependent property).

[Gcenx]

I’m not sure about the Linux environment but Darwin will be moved over to buster.

[qparis]

Darwin should not cause any trouble. Why do you need it to be moved over by the way?

[Gcenx]

After we moved over to using 10.13 SDK I had to start using clang-7 but the custom one seems to be missing some build time dependencies that are needed. (I’ll make an issue late about that)

And since we can’t be sure of if the custom clang was changed until CrossOver19 source is uploaded I’d rather move over to buster to get more upto date tools since I’m still wanting to add additional dependencies and simplify the environment.

[qparis]

Make sense

[Gcenx]

The update is done just cleanup/testing to ensure everything work as expected.

It copies in pre-made clang/clang++ wrappers, symlinks are created to gcc/g++/etc. This mean building is simplified;

./configure --host i386-apple-darwin17
./configure --host x86_64-apple-darwin17

So setting CC/CXX shouldn’t be needed in most cases

Gotten the cmake wrapper working by patching it to use the provided clang/clang++ wrappers since o32/o64-clang/++ never seemed to work.

i386-apple-darwin17-cmake
x86_64-apple-darwin17-cmake

Added a patch I’d found for ncurses 6.1 to correctly allow selection of strip.

I think all that’s left is adding ld override within the clang wrappers so we no longer need to symlink in the osxcross version all the time.

[qparis]

This is really great! Congratulation! Are you going to open a merge request for this?

[Gcenx]

Yep once I’m finished with it, I’ll push the branch and open the merge request.

[Gcenx]

@qparis well looks like I need to hold off on that upgrade to buster the included version of mingw-w64 breaks wine compilations.

I'll test if the version of mingw-w64 from backports works (I’ll check that later), it's that or just using the llvm repository to install clang-10 into the stretch image and add all the modifications I did to the Buster image.

So Debian Buster provides Mingw-w64 6.0.0-3 that’s bugged

Edit; I’ll come back to this later at the moment I’m busy with somethings, osxcross also doesn’t set pkg-config folder location correctly for macports location meaning it doesn’t add pc config files to the correct location...

Edit2; The mingw package has been fixed since I’d last tested this making it safe to now use buster @qparis already made the changes changes within the Darwin environment.