# [Solved] KDE-Update v. 4.10.0 zu 4.10.1 u. kdepim is broken

## Randy Andy

Man Leute,

man hab ich 'ne Odyssee hinter mir und die Faxen ziemlich dicke! (Details wen's interessiert unten, nach den Fakten*)

Dabei heißte es doch stets in den Annoucements das es lediglich um Bug-Fix-Releases handelt und diese eher unkritisch sind und daher empfohlen werden - Pustekuchen! Oder läuft das bei Euch problemlos und ich hab was falsch gemacht, oder muss mal wieder mit einem frischen Profil beginnen (da hab ich aber keine Bock drauf, dass kann's doch nicht sein - richtig?).

Die meisten Probleme Anderer schienen sich ja beim update von 4.9.5 zu 4.10.0 aufgetan zu haben, da gab's bei mir jedoch keine, nun aber um so mehr.

So vermeldet mir der Akonadi Server beim start von Kmail folgendes im Fehlerprotokoll:

- Akonadi-Steuerprogramm ist nicht am D-Bus registriert

- Akonadi-Serverprogramm ist nicht am D-Bus registriert

- keine Ressourcen-Vermittler gefunden

- Aktuelles Fehlerprotokoll des Akonadi Servers gefunden.

(Details/Logs erspar ich Euch hier, ist doch eh immer fast das gleiche Problem überall.)

Damit läuf dann quasi nix mehr von der Pim-Suite.

Habt ihr das auch, oder bereits gefixed, z.B. durch kompilieren mit Os statt O2 vom Paket xyz.

Oder durch anlegen eines frischen Profiles oder oder...

* Warum Odyssee?

Nun, ich dachte das update wäre eine willkommene Gelegenheit, mit Hilfe des kürzlich in den unstable Tree gewanderten gcc-4.7.2, sich die LTO (Link Time Optimization) zunutze zu machen.

Also, recherchiert wie's geht inclusive Gold linker nebst zugehöriger Optionen und Flags.

Alle neuen system und world pakete mit diesen kompiliert, außer denen die partout nicht damit wollen, diese wurden dann in die /etc/portage/package.env aufgenommen.

Zuvor wurde eine /etc/portage/env/no-lto.conf angelegt, alles auch hier sehr schön beschrieben: http://realnc.blogspot.de/2012/06/building-gentoo-linux-with-gcc-47-and.html

Als alles fertig war, aber KDE-Pim und Windows7-64Bit in der Virtual-Box bei mir quasi nicht mehr richtig lief dachte ich natürlich es läg an LTO.

Also einen Tag lang rumgetrickst und gefixed, jedoch ohne Erfolg.

Schließlich kapituliert, das System verworfen und das vorherige mit den alten Settings upgegradet (außer das nun gcc-4.7.2 statt 4.6.3 zum Einsatz kam), nur um letztlich festzustellen, dass das Problem das gleiche bleibt - toll. Wenn ich das vorher geahnt hätte, dann hätt ich doch noch eine Sicherung davon gezogen, wollte doch die Vorteile davon austesten - Mist verdammter!

Und Prelinking wollte ich dann noch obendrauf packen nun brauch ich aber erstmal wieder ein etwas Abstand und noch mehr Zeit bis zum nächsten Anluaf.

Trotzdem wär's ganz nett die 4.10.1er zum Laufen zu kriegen, sprich dieses fragile KDE-Pim Geraffel wieder zum Leben zu erwecken.

Da kann man schon ins Zweifeln geraten, liebe KDE-Dev's, wo Ihr's seit dem Akonadi-Framework doch eh nicht leicht habt, bei der ganzen Kritik daran.

Doch eigentlich zähl ich mich eher zu den Hart-Gesottenen - doch Ihr macht's einem nicht gerade leicht  :Wink: 

Gruß, Andy.

----------

## firefly

es kann immer noch am gcc 4.7.2 liegen.

Bei mir lief das upgrade auf 4.10.1 erfolgreich. Wobei ich 4.10.0 ausgelassen habe.

----------

## franzf

Du verwendest nicht zufällig das sqlite-backend von akonadi?

Hier ging das Update von 4.10.0 nach 4.10.1 auch recht problemlos (unlock dialog ist immer noch etwas - broken...).

----------

## Randy Andy

Hi firefly.

Ich hatte befürchtet das Du (oder einer der Antwortenden) so etwas sagen würdest, wegen der damit verbundenen Kosequenzen   :Crying or Very sad: 

Gibt's schon Statistiken/Bug-Reports die das belegen?

Denn schließlich dürfte doch dann Niemand mit gcc-4.7.2 kdepim ans laufen kriegen.

Sehe gerade im Unterschied zu vorher hab ich nun noch -fomit-frame-pointer in meinen CFLAGS mit drin, doch daran sollte es doch eigentlich nicht liegen können.

Gruß, Andy.

----------

## Randy Andy

Hi Franz.

 *franzf wrote:*   

> Du verwendest nicht zufällig das sqlite-backend von akonadi?
> 
> Hier ging das Update von 4.10.0 nach 4.10.1 auch recht problemlos (unlock dialog ist immer noch etwas - broken...).

 

Nein, ich verwende das mysql backend, allerdings mit mariadb als drop in replacement. Lief bis jetzt eigentlich reibungslos.

[Edit]

Frage an Franz. Nutzt Du wie ich den ~amd64 Zweig und auch den gcc-4.7.2?

Dann kann ich besser etwas ausschließen...

[Edit2, aus Josef wird Franz, aber sonst ändert sich nix - sorry]

Andy.

----------

## franzf

xD ich heiß immer noch Franz...

Nein, ich hab nicht komplett ~amd64. Bin mit gcc-4.6.3 unterwegs. Ich kann mir auch nicht so recht vorstellen, dass gcc-4.7.2 nicht lauffähige binaries erstellen sollte. Meistens bereiten Compiler-updates nur Probleme beim Kompilieren (z.B. Aufräumen bei nicht benötigten includes in headern, auf die sich aber manche Programmierer verlassen -> bamm: unbekannter Type).

Vor allem scheint ja der Rest zu laufen.

Poste doch einfach mal die akonadi-logs/akonadi check/emerge --info akonadi-server.

----------

## Randy Andy

Sorry Franz,

kommt wohl davon wenn man gleichzeitig in mehreren Foren unterwegs ist.

Hie ein paar Infos zur Analyse:

Das Fehlerprotokoll des MySQL-Servers

```
130310 15:11:57 InnoDB: The InnoDB memory heap is disabled

130310 15:11:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins

130310 15:11:57 InnoDB: Compressed tables use zlib 1.2.7

130310 15:11:57 InnoDB: Using Linux native AIO

/usr/sbin/mysqld: relocation error: /usr/sbin/mysqld: symbol io_getevents, version LIBAIO_0.4 not defined in file libaio.so.1 with link time reference
```

akonadictl start Ausgabe

```
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)

andy@big-server ~ $ search paths:  ("/usr/local/bin", "/usr/bin", "/bin", "/opt/bin", "/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3", "/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.2", "/usr/lib64/opencascade-6.5/ros/lin/bin", "/usr/games/bin", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 

Database process exited unexpectedly during initial connection!

executable: "/usr/sbin/mysqld"

arguments: ("--defaults-file=/home/andy/.local/share/akonadi/mysql.conf", "--datadir=/home/andy/.local/share/akonadi/db_data/", "--socket=/home/andy/.local/share/akonadi/socket-big-server/mysql.socket")

stdout: ""

stderr: ""

exit code: 127

process error: "Unknown error"

"[

0: akonadiserver(_Z11akBacktracev+0x34) [0x458804]

1: akonadiserver() [0x458b41]

2: /lib64/libc.so.6(+0x38090) [0x7ffc2154b090]

3: /lib64/libc.so.6(gsignal+0x35) [0x7ffc2154b015]

4: /lib64/libc.so.6(abort+0x17b) [0x7ffc2154c48b]

5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x7ffc23017a04]

6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0x9b) [0x45aa4b]

7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xaf) [0x7ffc230b2f6f]

8: /usr/lib64/qt4/libQtCore.so.4(+0x11e69b) [0x7ffc230be69b]

9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x39) [0x7ffc230c7079]

10: akonadiserver(_ZN13DbConfigMysql19startInternalServerEv+0x179a) [0x4c71ea]

11: akonadiserver(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0xc7) [0x45b7a7]

12: akonadiserver(_ZN7Akonadi13AkonadiServerC1EP7QObject+0xa5) [0x45c725]

13: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x47) [0x45dd47]

14: akonadiserver(main+0x10a) [0x4522aa]

15: /lib64/libc.so.6(__libc_start_main+0xed) [0x7ffc2153791d]

16: akonadiserver() [0x452a81]

]

"

ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)

search paths:  ("/usr/local/bin", "/usr/bin", "/bin", "/opt/bin", "/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3", "/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.2", "/usr/lib64/opencascade-6.5/ros/lin/bin", "/usr/games/bin", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 

Database process exited unexpectedly during initial connection!

executable: "/usr/sbin/mysqld"

arguments: ("--defaults-file=/home/andy/.local/share/akonadi/mysql.conf", "--datadir=/home/andy/.local/share/akonadi/db_data/", "--socket=/home/andy/.local/share/akonadi/socket-big-server/mysql.socket")

stdout: ""

stderr: ""

exit code: 127

process error: "Unknown error"

"[

0: akonadiserver(_Z11akBacktracev+0x34) [0x458804]

1: akonadiserver() [0x458b41]

2: /lib64/libc.so.6(+0x38090) [0x7f1cbd953090]

3: /lib64/libc.so.6(gsignal+0x35) [0x7f1cbd953015]

4: /lib64/libc.so.6(abort+0x17b) [0x7f1cbd95448b]

5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x7f1cbf41fa04]

6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0x9b) [0x45aa4b]

7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xaf) [0x7f1cbf4baf6f]

8: /usr/lib64/qt4/libQtCore.so.4(+0x11e69b) [0x7f1cbf4c669b]

9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x39) [0x7f1cbf4cf079]

10: akonadiserver(_ZN13DbConfigMysql19startInternalServerEv+0x179a) [0x4c71ea]

11: akonadiserver(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0xc7) [0x45b7a7]

12: akonadiserver(_ZN7Akonadi13AkonadiServerC1EP7QObject+0xa5) [0x45c725]

13: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x47) [0x45dd47]

14: akonadiserver(main+0x10a) [0x4522aa]

15: /lib64/libc.so.6(__libc_start_main+0xed) [0x7f1cbd93f91d]

16: akonadiserver() [0x452a81]

]

"

ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)

search paths:  ("/usr/local/bin", "/usr/bin", "/bin", "/opt/bin", "/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3", "/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.2", "/usr/lib64/opencascade-6.5/ros/lin/bin", "/usr/games/bin", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 

Database process exited unexpectedly during initial connection!

executable: "/usr/sbin/mysqld"

arguments: ("--defaults-file=/home/andy/.local/share/akonadi/mysql.conf", "--datadir=/home/andy/.local/share/akonadi/db_data/", "--socket=/home/andy/.local/share/akonadi/socket-big-server/mysql.socket")

stdout: ""

stderr: ""

exit code: 127

process error: "Unknown error"

"[

0: akonadiserver(_Z11akBacktracev+0x34) [0x458804]

1: akonadiserver() [0x458b41]

2: /lib64/libc.so.6(+0x38090) [0x7f137e2f2090]

3: /lib64/libc.so.6(gsignal+0x35) [0x7f137e2f2015]

4: /lib64/libc.so.6(abort+0x17b) [0x7f137e2f348b]

5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x7f137fdbea04]

6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0x9b) [0x45aa4b]

7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xaf) [0x7f137fe59f6f]

8: /usr/lib64/qt4/libQtCore.so.4(+0x11e69b) [0x7f137fe6569b]

9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x39) [0x7f137fe6e079]

10: akonadiserver(_ZN13DbConfigMysql19startInternalServerEv+0x179a) [0x4c71ea]

11: akonadiserver(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0xc7) [0x45b7a7]

12: akonadiserver(_ZN7Akonadi13AkonadiServerC1EP7QObject+0xa5) [0x45c725]

13: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x47) [0x45dd47]

14: akonadiserver(main+0x10a) [0x4522aa]

15: /lib64/libc.so.6(__libc_start_main+0xed) [0x7f137e2de91d]

16: akonadiserver() [0x452a81]

]

"

ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)

search paths:  ("/usr/local/bin", "/usr/bin", "/bin", "/opt/bin", "/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3", "/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.2", "/usr/lib64/opencascade-6.5/ros/lin/bin", "/usr/games/bin", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 

Database process exited unexpectedly during initial connection!

executable: "/usr/sbin/mysqld"

arguments: ("--defaults-file=/home/andy/.local/share/akonadi/mysql.conf", "--datadir=/home/andy/.local/share/akonadi/db_data/", "--socket=/home/andy/.local/share/akonadi/socket-big-server/mysql.socket")

stdout: ""

stderr: ""

exit code: 127

process error: "Unknown error"

"[

0: akonadiserver(_Z11akBacktracev+0x34) [0x458804]

1: akonadiserver() [0x458b41]

2: /lib64/libc.so.6(+0x38090) [0x7f877b9d0090]

3: /lib64/libc.so.6(gsignal+0x35) [0x7f877b9d0015]

4: /lib64/libc.so.6(abort+0x17b) [0x7f877b9d148b]

5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x7f877d49ca04]

6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0x9b) [0x45aa4b]

7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xaf) [0x7f877d537f6f]

8: /usr/lib64/qt4/libQtCore.so.4(+0x11e69b) [0x7f877d54369b]

9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x39) [0x7f877d54c079]

10: akonadiserver(_ZN13DbConfigMysql19startInternalServerEv+0x179a) [0x4c71ea]

11: akonadiserver(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0xc7) [0x45b7a7]

12: akonadiserver(_ZN7Akonadi13AkonadiServerC1EP7QObject+0xa5) [0x45c725]

13: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x47) [0x45dd47]

14: akonadiserver(main+0x10a) [0x4522aa]

15: /lib64/libc.so.6(__libc_start_main+0xed) [0x7f877b9bc91d]

16: akonadiserver() [0x452a81]

]

"

ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)

"akonadiserver" crashed too often and will not be restarted!
```

Seltsam finde ich dass ich seit Tagen mein installiertes mariadb nicht mehr rekompilieren kann, obwohl es laut revdep-rebuild nicht gebrochen ist.

Hab's auch gerade mal mit gcc-4.6.3 versucht, geht auch nicht. https://bugs.gentoo.org/show_bug.cgi?id=461260

Braucht Ihr sonst noch was...

Danke, Andy.

----------

## firefly

 *Randy Andy wrote:*   

> 
> 
> Das Fehlerprotokoll des MySQL-Servers
> 
> ```
> ...

 

Da haben wir den eigentlichen Fehler nur komisch, dass bei dir mariadb nicht mehr gebaut werden kann. Mit was für einen Fehler bricht er denn ab?

Ich habe mariadb 5.1.66 am laufen, welches mit folgenden use-flags gebaut ist:

 *Quote:*   

>  dev-db/mariadb:0::gentoo 5.1.66 to ::installed replacing 5.1.66
> 
>     berkdb -big-tables -cluster community -debug embedded -extraengine -latin1 -libevent -max-idx-128 -minimal -pbxt -perl -profiling (-selinux) ssl -static (-test) build_options: symbols=split -dwarf_compress -optional_tests -trace work=tidyup

 

Edit: ich habe gerade deinen bugreport gelesen. In der Build ausgabe fehlt der eigentliche fehler. Am besten du hängst dort das komplette build.log an.

----------

## Randy Andy

Danke Leute.

Hab gerade das build.log dran gehangen. Hätt ich ja schon vorher gemacht, aber immer diese lächerlichen Speicherlimitierungen auf nicht mal 2MB machen die Sache halt nicht sehr Benutzerfreundlich.

Gruß, Andy.

----------

## firefly

So Fehler gefunden:

 *Quote:*   

> /var/tmp/portage/dev-db/mariadb-5.5.29/work/mariadb-5.5.29_build/libmysqld/examples && /usr/bin/cmake -E cmake_link_script CMakeFiles/mysql_embedded.dir/link.txt --verbose=1
> 
> /usr/bin/x86_64-pc-linux-gnu-g++   -Wall -march=core2 -mtune=core2 -O2 -pipe -fomit-frame-pointer -fno-exceptions -fno-strict-aliasing -felide-constructors -fno-rtti -fno-implicit-templates -fno-strict-aliasing  -Wno-unused-parameter -fno-implicit-templates -fno-exceptions -fno-rtti -O2 -g -DNDEBUG -DDBUG_OFF  -ltcmalloc -Wl,--export-dynamic CMakeFiles/mysql_embedded.dir/__/__/client/completion_hash.cc.o CMakeFiles/mysql_embedded.dir/__/__/client/mysql.cc.o CMakeFiles/mysql_embedded.dir/__/__/client/readline.cc.o  -o mysql_embedded  -lpthread ../libmysqld.a -lreadline -lcurses -lpthread -lz -lm -lrt -lssl -lcrypto -lcrypt -ldl -laio 
> 
> /lib64/libaio.so.1: undefined reference to `io_getevents'

 

Hast du schon versucht libaio neu zu bauen? bzw. dessen Abhängigkeiten?

----------

## Randy Andy

Danke firefly,

Das war mir Gestern auch schon aufgefallen (s.u.), worauf hin ich libaio neu gebaut hatte.

Dann bin ich auch noch auf die vorherige Version 0.3.109-r3 zurück gegangen, half aber auch nichts.

Ausserdem hatte ich noch diverse male alle dbus pakete neu bauen lassen. Dann noch python-updater und peral-cleaner --reallyall.

Immer wieder mit revdep-rebuild gecheckt etc.

Welche Abhängigkeiten? Ich seh da keine.

```

[I] dev-libs/libaio

     Available versions:  0.3.107^t 0.3.109-r2^t 0.3.109-r3 0.3.109-r4 {multilib static-libs test}

     Installed versions:  0.3.109-r4(22:08:21 09.03.2013)(multilib -static-libs -test)

     Homepage:            http://www.kernel.org/pub/linux/kernel/people/andrea/libaio/ http://lse.sourceforge.net/io/aio.html

     Description:         Asynchronous input/output library that uses the kernels native interface

```

----------

## firefly

es liegt direkt an libaio bzw. wie es gebaut wurde.

kannst du mal folgende ausgabe posten:

```
objdump -tT /lib64/libaio.so.1
```

edit: und durch welche pakete wurde libaio überhaupt mit installiert?

EDIT2: habe ne mögliche lösung. Du musst LTO für libaio deaktivieren, ansonsten werden ein paar symbole nicht mit in die lib gebaut.

Reference: https://bugs.gentoo.org/show_bug.cgi?id=459716 bzw. https://bugs.gentoo.org/show_bug.cgi?id=453938 --> LTO ist von gentoo nicht supported.

----------

## Randy Andy

Gerne firefly.

objdump -tT /lib64/libaio.so.1

```

SYMBOL TABLE:

no symbols

DYNAMIC SYMBOL TABLE:

00000000000004c0 l    d  .text  0000000000000000              .text                                                                  

0000000000000000      D  *UND*  0000000000000000              io_getevents                                                           

00000000000004f0 g    DF .text  0000000000000016  LIBAIO_0.1  io_queue_init                                                          

00000000000004d0 g    DF .text  0000000000000005  LIBAIO_0.1  io_queue_release                                                       

0000000000000000 g    DO *ABS*  0000000000000000  LIBAIO_0.4  LIBAIO_0.4                                                             

0000000000000520 g    DF .text  0000000000000049  LIBAIO_0.1  io_queue_run                                                           

00000000000004e0 g    DF .text  000000000000000b  LIBAIO_0.4  io_setup                                                               

00000000000004c0 g    DF .text  0000000000000008  LIBAIO_0.4  io_destroy                                                             

0000000000000510 g    DF .text  0000000000000008  LIBAIO_0.1  io_submit                                                              

0000000000000000 g    DO *ABS*  0000000000000000  LIBAIO_0.1  LIBAIO_0.1

```

Zu Frage 2:

equery d libaio                                                                                                   

```
 * These packages depend on libaio:                                                                                                  

dev-db/mariadb-5.5.29 (kernel_linux ? dev-libs/libaio)                                                                               

dev-util/strace-4.7 (aio ? >=dev-libs/libaio-0.3.106)
```

Sollte ich libaio ohne multilib use-flag bauen oder was meinst du mit anders bauen?

Ups, sehe gerade dein Edit2 und probiere das gleich mal aus und melde mich dann wieder, bin aber gerade etwas busy.

----------

## firefly

 *Randy Andy wrote:*   

> Gerne firefly.
> 
> objdump -tT /lib64/libaio.so.1
> 
> ```
> ...

 

Da haben wir das problem, wie ich mir schon durch die beiden bugreports gedacht habe. In libaio ist die mehtode io_getevents als undefined markiert, obwohl diese von der lib selbst bereitgestellt wird.

----------

## Randy Andy

Firefly Du hast's drauf.

hab tatsächlich libaio gerade mit gcc-4.6.3 rekompiliert und schon klappt's, kmail geht wieder etc.

Hier zum Vergleich der dump wenn's läuft:

objdump -tT /lib64/libaio.so.1

```

/lib64/libaio.so.1:     file format elf64-x86-64

SYMBOL TABLE:

no symbols

DYNAMIC SYMBOL TABLE:

0000000000000660 l    d  .text  0000000000000000              .text

0000000000000680 g    DF .text  0000000000000005  LIBAIO_0.1  io_queue_release

0000000000000000 g    DO *ABS*  0000000000000000  LIBAIO_0.1  LIBAIO_0.1

0000000000000660 g    DF .text  0000000000000016  LIBAIO_0.1  io_queue_init

0000000000000000 g    DO *ABS*  0000000000000000  LIBAIO_0.4  LIBAIO_0.4

0000000000000770 g    DF .text  0000000000000008  LIBAIO_0.4  io_destroy

0000000000000760 g    DF .text  000000000000000b  LIBAIO_0.4  io_setup

0000000000000690 g    DF .text  000000000000000e  LIBAIO_0.4  io_queue_wait

00000000000007a0 g    DF .text  000000000000002f (LIBAIO_0.1) io_queue_wait

00000000000007d0 g    DF .text  0000000000000034 (LIBAIO_0.1) io_getevents

0000000000000700 g    DF .text  0000000000000035  LIBAIO_0.4  io_getevents

00000000000006a0 g    DF .text  0000000000000049  LIBAIO_0.1  io_queue_run

0000000000000740 g    DF .text  0000000000000008  LIBAIO_0.1  io_submit

0000000000000780 g    DF .text  0000000000000011 (LIBAIO_0.1) io_cancel

0000000000000750 g    DF .text  0000000000000008  LIBAIO_0.4  io_cancel

```

Entweder ist mir das kleine Biest noch durchgeschlüpft mit den alten LTO Settings, oder es liegt am gcc-4.7.2.

Werde das noch in Ruhe versuchen zu differenzieren und auch ob nun mariadb wieder kompiliert.

Womöglich ist das also so ein Kandidat der zwar durchkompiliert, aber dann doch den von Dir beschriebenen Fehler zeigt.

Leider fehlen mir noch die Programmierkenntnisse um das zu verstehen und um selbst darauf zu kommen.

Jedenfalls herzlichen Dank, hast'n Bier gut bei mir (muss ja nicht unbedingt 'n Kölsch sein, falls Dir unser Ortsansässiges nicht zusagt)   :Wink: 

Gebe dann viel später gerne noch weitere Details.

[Edit]

Auch wenn libaio mit gcc-4.7.2 kompiliert wurde läuft's wieder wie gewünscht.

Mariadb baut auch damit wieder erfolgreich. 

Also lag es doch alles daran, dass ich wieder versehentlich die libaio mit dem lto flag gebaut hatte.

Dumm gelaufen, sorry für die unnötige Arbeit. Markiere den Thread nun als solved.

Einstweilen herzlichen Dank.

Gruß an alle Beteiligten, Andy.

----------

