You are not logged in.

#1 2014-08-17 23:34:24

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Massively Multilib Upstream Game

This actually started with wanting to compile upstream dependencies for the lastest version of PCSX2, but it's quickly growing out of control.

I've put together a number of upstream (git/bzr/git+bzr) -multilib packages as well as several lib32- packages that I couldn't find anywhere else, or couldn't find in a usable state.

I still could use some help! gobject-introspection is causing all kinds of trouble and therefore I'm disabling it almost everywhere. My packages could use a few extra pairs of eyes to make sure I'm doing things within policy. Once these packages are all in good order, I intend to upload them to AUR (some I already have!)

I made a repository for the packages: Massively Multilib Upstream Game

I'd appreciate any advice!

Last edited by quequotion (2015-01-12 00:51:16)

Offline

#2 2014-08-18 08:56:00

Awebb
Member
Registered: 2010-05-06
Posts: 6,275

Re: Massively Multilib Upstream Game

I wonder why it is still 32bit packaged. I was under the impression, that PCSX2 builds fine on 64bit.

Offline

#3 2014-08-18 10:25:53

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Massively Multilib Upstream Game

quequotion,

Are you aware of the pcsx2-git pacakge in aur ?

If not, i suggest you contact alucryd .


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#4 2014-08-18 12:47:59

GordonGR
Member
From: Thessaloniki, Greece
Registered: 2011-11-07
Posts: 276

Re: Massively Multilib Upstream Game

quequotion wrote:

I can't get lib32-gstreamer or lib32-gst-plugins-base to compile

I don't suppose you can make do with aur/lib32-gstreamer0.10-* that all build properly?


Intel(R) Celeron(R) CPU E3400 @ 2.60GHz, x86_64. AURs.

“No one without the knowledge of geometry may enter.“ Plato.

Offline

#5 2014-08-18 14:33:33

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

Lone_Wolf wrote:

Are you aware of the pcsx2-git pacakge in aur ?

I have a local copy of the aur-alucryd git repo!
I want to compile pcsx2-git with wxgtk3-no-stl-gtk3 (WxGTK version 3 without STL and with GTK+3 widgets) because I want it to match the rest of my desktop, which means compiling lib32-wxgtk3-no-stl-gtk3. This package should be entirely possible, but many of the lib32- dependencies had not yet been packaged for Archlinux (or for anything...). This also gave me an opportunity to learn a lot more about packaging and the intricacies of things like autoconf and cmake (or sed and diff/patch when playing nice doesn't work).

GordonGR wrote:

I don't suppose you can make do with aur/lib32-gstreamer0.10-* that all build properly?

Unfortunately not, the other lib32- packages like lib32-qt5 depend on gsreamer-1.x  **EDIT** By the way, I also needed to install a bunch of your lib32- packages from AUR; thanks!

Last edited by quequotion (2015-01-12 00:53:42)

Offline

#6 2014-08-18 15:10:24

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

Awebb wrote:

I wonder why it is still 32bit packaged. I was under the impression, that PCSX2 builds fine on 64bit.

The software itself is 32bit (a 64bit branch once existed, but the lead developer was lost and the others are convinced that porting to 64bit is somehow a bad thing); multilib has advanced enough that it is usually possible to build this on x86_64 these days, but the PCSX2 devs are working with very upstream libraries. Luckily Arch is also very upstream, so it usually isn't a problem.

Offline

#7 2014-08-19 12:43:22

GordonGR
Member
From: Thessaloniki, Greece
Registered: 2011-11-07
Posts: 276

Re: Massively Multilib Upstream Game

quequotion wrote:
GordonGR wrote:

I don't suppose you can make do with aur/lib32-gstreamer0.10-* that all build properly?

Unfortunately not, the other lib32- packages like lib32-qt5 depend on gsreamer-1.x.

I suspected, but still I felt compelled to ask, lol.  Yw, all I do is update them lol.


Intel(R) Celeron(R) CPU E3400 @ 2.60GHz, x86_64. AURs.

“No one without the knowledge of geometry may enter.“ Plato.

Offline

#8 2014-08-19 21:09:43

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

The lib32-gst packages will build with introspection disabled!

Offline

#9 2014-08-20 04:36:47

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

lib32-qt5 depends on lib32-postgresql, lib32-postgresql depends on lib32-perl, lib32-perl depends on lib32-networkmanager, lib32-networmanager depends on lib32-qt5 lib32-qt4! (which I already have installed? looks like another repackage to be done...)

lib32-qt5 depends on lib32-gst-plugins-base, lib32-gst-plugins-base depends on lib32-qt5

I hacked my way around the qt5/gst-plugins-base loop by commenting out all the qt stuff in gstreamer (which will have to be rebuilt once lib32-qt5 is installed)...

::EDIT::

lib32-qt4 depends on lib32-postgresql, lib32-posgresql depends on lib32-perl, lib32-perl depends on lib32-networkmanager, lib32-networkmanager depends on lib32-qt4


Why does perl need networkmanager? I really can't imagine the reason that a script parser depends on a specific network management tool.

Last edited by quequotion (2014-08-22 20:29:41)

Offline

#10 2014-08-20 10:40:42

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

Just thought I'd share this little gem from lib32-networkmanager-git's config.log (it's not the only nor the most important error):

conftest.cpp:28:28: fatal error: ac_nonexistent.h: No such file or directory
 #include <ac_nonexistent.h>
                            ^
compilation terminated.

Offline

#11 2014-08-22 03:47:47

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

This project has brought to my attention that we need (better) policy regarding lib32 packages.

Most of the lib32 packages available in the arch repository are libraries only and I find myself repackaging a lot of stuff that has architecture-specific includes which are needed by dependents.
For the time being I'm putting these in "/usr/lib32/pkgname/include/(pgkname/include)"; some of the packages expect "/usr/include", and so are hard-coded to append "pkgname/include" to separate their files.

Two questions that need policy answers:

1. Should lib32 packages have their includes included? (considering that dependents need them to build I hope the answer is yes)
2. Where should 32bit includes go? (/usr/include32 looks silly to me, but what's better?)

Offline

#12 2014-08-22 10:47:05

GordonGR
Member
From: Thessaloniki, Greece
Registered: 2011-11-07
Posts: 276

Re: Massively Multilib Upstream Game

quequotion wrote:

Two questions that need policy answers:

1. Should lib32 packages have their includes included? (considering that dependents need them to build I hope the answer is yes)
2. Where should 32bit includes go? (/usr/include32 looks silly to me, but what's better?)

I can't answer the former, but for the latter I maintain one such package. The previous maintaner (and I kept his way), put it in /usr/lib32/pkgconfig/, like that:

nikos@Russell:~$ pacman -Ql lib32-libmodplug
lib32-libmodplug /usr/
lib32-libmodplug /usr/lib32/
lib32-libmodplug /usr/lib32/libmodplug.so
lib32-libmodplug /usr/lib32/libmodplug.so.1
lib32-libmodplug /usr/lib32/libmodplug.so.1.0.0
lib32-libmodplug /usr/lib32/pkgconfig/
lib32-libmodplug /usr/lib32/pkgconfig/libmodplug.pc
lib32-libmodplug /usr/share/
lib32-libmodplug /usr/share/licenses/
lib32-libmodplug /usr/share/licenses/lib32-libmodplug

Make sure to sed it properly so it points to the lib32- so's and not the actual 64bits ones, like that:

# Modify libmodplug.pc
cd "${pkgdir}/usr/lib32/pkgconfig"
sed -i 's|includedir=${prefix}/include|includedir=${prefix}/include/libmodplug/|' libmodplug.pc
}

Last edited by GordonGR (2014-08-22 10:48:43)


Intel(R) Celeron(R) CPU E3400 @ 2.60GHz, x86_64. AURs.

“No one without the knowledge of geometry may enter.“ Plato.

Offline

#13 2014-08-22 12:42:51

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Massively Multilib Upstream Game

quequotion wrote:

This project has brought to my attention that we need (better) policy regarding lib32 packages.

Most of the lib32 packages available in the arch repository are libraries only and I find myself repackaging a lot of stuff that has architecture-specific includes which are needed by dependents.
For the time being I'm putting these in "/usr/lib32/pkgname/include/(pgkname/include)"; some of the packages expect "/usr/include", and so are hard-coded to append "pkgname/include" to separate their files.

Two questions that need policy answers:

1. Should lib32 packages have their includes included? (considering that dependents need them to build I hope the answer is yes)
2. Where should 32bit includes go? (/usr/include32 looks silly to me, but what's better?)

Queqotion,

I got he impression majority of lib32-* libraries use headers/includes supplied by their 64-bit versions .

Or are you refering to libraries WITHOUT 64-bit versions ?

Also this issue looks like it may require changes to arch packaging standards, you might want to take it to arch-general ML ( and maybe ask a TU/Dev to re-post it to arch-dev-public ) .


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#14 2014-08-22 14:59:34

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

Lone_Wolf wrote:

I got he impression majority of lib32-* libraries use headers/includes supplied by their 64-bit versions .

Most probably can, but some have architecture-specific includes. Python's includes, for example, define the size of data types (long_int, etc); 32bit programs cannot be compiled with 64bit data types and vice versa, so the includes must be installed and kept separate from other architecture's includes.

Also this issue looks like it may require changes to arch packaging standards, you might want to take it to arch-general ML ( and maybe ask a TU/Dev to re-post it to arch-dev-public ) .

When I've got this series of packages worked out, I will do just that (having a functional set of packages and a use case will help back up my argument).

GordonGR wrote:

Make sure to sed it properly so it points to the lib32- so's and not the actual 64bits ones, like that:

# Modify libmodplug.pc
cd "${pkgdir}/usr/lib32/pkgconfig"
sed -i 's|includedir=${prefix}/include|includedir=${prefix}/include/libmodplug/|' libmodplug.pc
}

Thanks for this! I'm going to have to add it to a few packages.

Offline

#15 2014-08-23 21:11:40

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

Another marvelous message from a failed compile (lib32-qt4, which I have almost worked out):

Warning: Property declaration writeOnlyProperty has no READ accessor function. The property will be invalid.

Offline

#16 2014-08-24 09:43:31

GordonGR
Member
From: Thessaloniki, Greece
Registered: 2011-11-07
Posts: 276

Re: Massively Multilib Upstream Game

But lib32-qt4 is in [multilib] (a Skype dependency). Why would you want to rebuild it?


Intel(R) Celeron(R) CPU E3400 @ 2.60GHz, x86_64. AURs.

“No one without the knowledge of geometry may enter.“ Plato.

Offline

#17 2014-08-24 11:32:05

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

GordonGR wrote:

But lib32-qt4 is in [multilib] (a Skype dependency). Why would you want to rebuild it?

Missing includes, etc.

Edit: The includes are needed for things that depend on lib32-qt4 to build, Skype is a binary package, so it only needs the compatibility libraries.

Edit again: in particular, lib32-qt4 (with headers and pkgconfig) is needed for building lib32-poppler and lib32-networkmanager

Last edited by quequotion (2014-08-24 12:50:21)

Offline

#18 2014-08-26 10:24:01

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

oh wow, the wasted time!

finally got all the needed packages to build, only to realize that pcsx2 isn't building its whole interface with wxWidgets and is apparently not wxwidgets3-gtk3 compatible.. I had assumed wxWidgets worked between the toolkit and the codebase such that it would render widgets in whichever toolkit it was compiled for from wxwidget-native code.. apparently not the case...

well, the good news is i have a bunch of new lib32 packages to contribute (although i still need to get on the mailing list to ask for policy regarding architecture specific includes in lib32 packages)...

Offline

#19 2014-08-26 10:56:05

Awebb
Member
Registered: 2010-05-06
Posts: 6,275

Re: Massively Multilib Upstream Game

While I have nothing of value to contribute, I would like to tell you, that I very much appreciate your efforts, quequotion!

Offline

#20 2014-08-26 18:48:50

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

Awebb wrote:

While I have nothing of value to contribute, I would like to tell you, that I very much appreciate your efforts, quequotion!

Thank you! Perhaps the mulitlib and extra lib32 packages will be useful to someone somewhere.

I'm also setting up a place to work on pcsx2-gtk3-git, and a branch of wxgtk3 with the lib32 component using gtk2.

::EDIT::

Furthermore, brains.......

Last edited by quequotion (2014-08-26 18:52:04)

Offline

#21 2015-01-10 11:33:33

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

Good news?

I got back around to this project and made some serious improvements to the multilib packages (not yet pushed out to git), then I find gtk3 and sdl2 support is actually being worked on upstream. It looks like pcsx2-gtk3-sdl2(-git) may be a reality soon!

I need to go over the lib32- dependencies again (although basic x86_64 support should also be available in pcsx2-git) and verify which arch repo and aur packages are broken (missing architecture-specific headers, actually x86_64, etc) and if any are newly available.

In the mean time, I've begun the process of uploading the packages to AUR!

lib32-qt5 and several others went up today, but they may still need dependencies from my git repo to build.

Dependency hell: wxgtk3-no-stl-gtk3-git-multilib needs webkit-git-multilib which needs gst-plugins-bad-git-multilib which needs lib32-dependencies that do not yet exist.
::UPDATE::
Good news: Worked that out! Built all the gst-plugins-*-git-multilib and wxgtk3-no-stl-gtk3-git-multilib.
Bad news: By giving up on hopelessly huge webkit and disabling related components in wxgtk. Still need to go over the git logs to see how the gstreamer situation was resolved.

Last edited by quequotion (2015-04-30 06:44:40)

Offline

#22 2015-04-30 06:25:24

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: Massively Multilib Upstream Game

::UPDATE::

PCSX2 is making progress. WX3-GTK3, and SDL2 builds, without special multilib precautions*, are theoretically possible now.
I can't get it to work. Then again, I'm trying to force it to build without debug flags (mandatory for GTK3_API) so there's that...

*Not quite 64bit, just checking it's 32bit dependencies (more or less) correctly in cmake.

The best this ever worked for me was, just once, to compile pcsx2 with WX3-GTK2 and SDL2; sdl2 support was buggy at the time.

Now build is crashing because CMAKE can't find GTK3... I've compiled and recompiled wxgtk3-no-stl-gtk3-git-multilib so many times... I've compiled and recompiled gtk3-git{,-ubuntu}-multilib many times... I did fix a problem with SDL2, but CMAKE still can't find GTK3....


Introducing: glibc-git-multilib

Note: much more broken than I thought; apparently there are limits to --enable-kernel=?.?.? needs more research.

Just like the others, the idea here is to save time and bandwidth by downloading the source only once, then build both architecture's packages from it.

Still, compiling glibc takes a long time! Compiling dual-arch glibc will take twice as long!

Last edited by quequotion (2015-05-01 11:00:16)

Offline

Board footer

Powered by FluxBB