On Wed, 25 Jun 2008 08:15:20 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
Hi Lucas,
On Wed, Jun 25, 2008 at 11:09:31 +1000, Lucas Hazel wrote:
Some configure scripts automatically detect the presence of libraries, on a single library system this isn't a problem. However, when building 32bit support libraries on a mixed 32/64bit system the 64bit libraries get detected, but not tested by the configure script, only to fail during the linking process.
Interesting problem. From your script it seems that if the compat port of that soft dependency is installed, it will work again, did I read that correctly?
That's correct. You either remove the 64bit port, build it, reinstall the 64bit port or install the compat32 port and build again.
Would it be a pkg-config problem then, or how is the wrong library detected by configure?
If only everyone used pkg-config, things would be a lot easier. In pkgmk.conf I just set PKG_CONFIG and PKGCONFIG (make up your mind dammit!) to /usr/bin/pkg-config32, which solves a lot of the auto detection problems (pkg-config --exists). However there are still a collection of ports that ship with their own *-config script. This is where the problems exist. Initially *_CONFIG=/usr/bin/*-config needs to be set in pkgmk.conf (a pkgmk.conf.d would be nice ;) ), however I found that some will fall back to just detecting the presence of headers and the problem is back again. That said, I've only come across 2 ports that need the compat32_dep_check hack (but there may be a better solution), gtk-compat32 and libxslt-compat32.
I'd like to look at one of these to get a better idea, is cups a good example?
I have the ports available on http://git.die.net.au/cgit compat32 and multilib ports are available for core, opt and xorg. I'd like to see how mine are different from the pure64 alternative, as I suspect that other than a few core ports, not much will be different. If you want to clone core for example it's git://git.die.net.au/crux/ports/core
It is not feasible to add all soft deps to the compat32 Pkgfile so these need to be detected. Rather than let these fail and let the user figure it out, I've come up with a solution, but I'm not sure how it would bode with with CRUX philosophy. Would it also be possible to disable the soft dependencies explicitely? I think you mentioned something like this for libxslt. Or the other way around, adding the compat32 ports as hard dependencies.
Both are just workarounds, though, but depending on the number of ports we'll end up with in compat32 could also be feasible.
As I said, I'm not sure if this sits will with the CRUX way of doing things, such as enforcing dependencies. But it's a necessary evil to get compat32 ports to compile cleanly. That or we can let the end user figure out the soft deps on their own. One thing I'm not sure yet is how many compat port we will end up in the long run, i.e. whether it's okay to cover to typical use cases, or whether we need more and more over time since users want more ports.
I'm up to 64 compat32 ports, which was about how many I had before I started the new repos. The bulk of this is xorg and gtk stuff, which should be enough get get a lot of popular 32bit binary programs to work (flash, acroread, wine). There may be a few more compat32 ports needed, but I belived most of the groundwork has been laid here.
If the compat ports are an small set, then I think it could be okay to add a special solution, especially since I still hope that at some point in time we'll be able to drop the compat ports altogether, although that may take some years... I'll have to think a bit longer about the way you implemented it (lack of coffee and such).
There's probably a better solution, but as the saying goes, a bad solution is better than no solution at all. If the number of cases that have soft deps turns out to be quite small it would be quite feasible to simply write it into the Pkgfile for each case.
The one thing I'd like to avoid is that the method as is is picked up by other packagers to run random scripts in Pkgfiles, because they see it in our ports (you know, like running pre-install from there).
^^ I just wrote the drop in script because I had a fear that I would end up writing the same few lines over and over, which in the end turned out to be for only 2 cases. Hopefully there'll be a way to get around it, but for now it's working.
I'm not sure how interested the rest of you are in multilib, but I'm not really interested in using a 64bit only system on my home desktop. I need to watch youtube videos and I need to be able to play GTA when the world is getting me down :) Heh. I'm pretty sure that the majority of our users today will have some 32-bit applications they want to run, so at this point multilib seems favourable to me. As mentioned I hope that we can go pure 64 at some point in time, but I don't see that happening anytime soon.
Well, I for one will be sticking with multilib regardless of which way the official version decides to go. Granted many mainstream programs will go 64bit in the end (I hear that flash10 will have 64bit linux support), redhad is working on an opensource java plugin, etc), unfortunately I don't think 32bit is going anyware for a long time. -- Lucas Hazel <lucas@die.net.au>