[oi-dev] Hi all, please some patience: Just to let you know, VirtualBox-5.1.4 builds and almost packages in my local hipster userland

Мартин Бохниг opensxce at mail.ru
Tue Sep 13 16:27:54 UTC 2016


Hi all, please some patience: Just to let you know, VirtualBox-5.1.4 builds and almost packages in my local hipster userland but so far without QT5 frontend. I tried to make it use QT4 via configure, but although this is still a supported configuration, in reality it is broken. That's why we really need QT5.

And atm I'm still waiting for QT5.5 to complete.
(currently on the screen:

ln -s libQt5Widgets.so.5.5.0 libQt5Widgets.so
ln -s libQt5Widgets.so.5.5.0 libQt5Widgets.so.5
ln -s libQt5Widgets.so.5.5.0 libQt5Widgets.so.5.5
rm -f ../../lib/libQt5Widgets.so.5.5.0
mv -f libQt5Widgets.so.5.5.0  ../../lib/
rm -f ../../lib/libQt5Widgets.so
rm -f ../../lib/libQt5Widgets.so.5
rm -f ../../lib/libQt5Widgets.so.5.5
mv -f libQt5Widgets.so ../../lib/
mv -f libQt5Widgets.so.5 ../../lib/
)


Ouch, new problem in QT5.5:


Undefined            first referenced
 symbol                  in file
qt_memfill16(unsigned short*, unsigned short, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_memfill32(unsigned int*, unsigned int, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
convert_ARGB_to_ARGB_PM_inplace_sse2(QImageData*, QFlags<Qt::ImageConversionFlag>)       /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_fetch_radial_gradient_sse2(unsigned int*, Operator const*, QSpanData const*, int, int, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_functionForModeSolid_SSE2        /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_scale_image_argb32_on_argb32_sse2(unsigned char*, int, unsigned char const*, int, int, QRectF const&, QRectF const&, QRect const&, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_functionForMode_SSE2             /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_bitmapblit16_sse2(QRasterBuffer*, int, int, unsigned int, unsigned char const*, int, int, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_bitmapblit32_sse2(QRasterBuffer*, int, int, unsigned int, unsigned char const*, int, int, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_bitmapblit8888_sse2(QRasterBuffer*, int, int, unsigned int, unsigned char const*, int, int, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_blend_argb32_on_argb32_sse2(unsigned char*, int, unsigned char const*, int, int, int, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
qt_blend_rgb32_on_rgb32_sse2(unsigned char*, int, unsigned char const*, int, int, int, int) /code/ALP__KMS_MATE__checkout20160911sun/oi-userland/components/qt5/build/i86/qtbase/lib/libQt5Gui.so
ld: fatal: symbol referencing errors. No output written to libqjpeg.so
collect2: error: ld returned 1 exit status
Makefile:171: recipe for target '../../../../plugins/imageformats/libqjpeg.so' failed
make[6]: *** [../../../../plugins/imageformats/libqjpeg.so] Error 1



5.7 needs extra work and 5.6 will be tested next, when I see if 5.6 builds without extra-hassle, I decide if we take 5.5 or 5.6 and then manually merge in the old qt4 diffs.

On this Celeron 2.4GHz will all storage connected via (so far) USB2 (the bridges are USB2.0, so no USB3 anyway) and with all of my pools always gzip-9 compressed, it always takes a while.

As for agpgart I now also found out why this problem is only visible on older hardware:

In openindiana/drm/build/amd64/i915/src/i915_gem_gtt.c

we have:

void
intel_rw_gtt(struct drm_device *dev,
        size_t size,
        uint32_t gtt_offset,
        void *gttp,
        uint32_t type)
{
        struct drm_i915_private *dev_priv = dev->dev_private;
        unsigned first_entry = gtt_offset >> PAGE_SHIFT;
        unsigned num_entries = size / PAGE_SIZE;
        uint32_t *gtt_addr;
        uint32_t *old_gtt = (uint32_t *)gttp;
        int i, j;

        if (INTEL_INFO(dev)->gen <= 5) {
                (void) drm_agp_rw_gtt(dev, size/PAGE_SIZE, gtt_offset,
                                        gttp, type);
        } else {
                if (type) {
                        for (i = first_entry, j = 0; i < ( first_entry + num_entries); i++, j++) {
                                gtt_addr = (uint32_t *)(uintptr_t)((caddr_t)dev_priv->gtt.virtual_gtt
                                                        + i * sizeof(uint32_t));
                                ddi_put32(dev_priv->gtt.gtt_mapping.acc_handle,
                                                gtt_addr, old_gtt[j]);
                        }
                } else {
                        for (i = first_entry; i < ( first_entry + num_entries); i++) {
                                gtt_addr = (uint32_t *)(uintptr_t)((caddr_t)dev_priv->gtt.virtual_gtt
                                                        + i * sizeof(uint32_t));
                                old_gtt[i] = ddi_get32(dev_priv->gtt.gtt_mapping.acc_handle,gtt_addr);
                        }
                }
        }
}



Now, I made a test if the higher than gen5 code works on <=gen5, but no (both parts if the if/else clause not).
This means living without AGPIOC_RW_GTT aware agpgart is *NOT* possible, which eliminates the second option of my available choices and brings me back straight to alternative #0 aka that I *must* make agpgart AGPIOC_RW_GTT ready.
As said before, with Sol11.3's agpgart stack the same i915/drm/kms bins do work unchanged even on old OpenSolaris kernels. It is only agpgart. More on that asap after I finally get QT5 and VirtualBox completed.


No response required, this is only an update which confirms that it all takes a bit longer that I had hoped but that I'm busy with it.


-- 
Мартин Бохниг
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20160913/f20747d6/attachment-0004.html>


More information about the oi-dev mailing list