DB-Konvertierung->Linux ? ERROR: F_KALENDERWOCHE not defi

[reberg]

Hallo,

ich habe eine Installation von AvERP und Firebird 2.5 unter Debian begonnen, und komme bei der Konvertierung der leeren Datenbank nicht weiter.

Zunächst mal: Das Debian ist ein AMD64-System mit Debian Squeeze.
Wie in diesem Thread beschrieben:
http://www.synerpy.de/phpBB2/viewtopic. ... enderwoche

habe ich erstmal die leere Datenbank von Synerpy heruntergeladen (AvERP2012.02.FDB) und diese mittels gbak linuxtauglich gemacht, bzw. es versucht:

1. Unter einem Windows-XP mit Firebird 2.5 führte ich durch:

Code: Alles auswählen

c:\programme\firebird\firebird_2_5\bin\gbak.exe -b -l -k -user sysdba -password masterke AvERP2012.02.fdb AvERP2010.02.fbk

2. Die resultierende .fbk - Datei kopiere ich auf das Linux-System und versuche wieder eine .FDB draus zu machen:

Code: Alles auswählen

gbak -r -k -l -user sysdba -password ****** AvERP2012.02.fbk /tmp/AvERP2012.02.linux.fdb

Dies führt zu
gbak: WARNING:function F_KALENDERWOCHE ist not defined
gbak: WARNING: module name or entrypoint could no tbe found

Getestet habe ich mit:
- Firebird Super 2.5 aus dem Debian-Paket
- den Debian-Firebird deinstalliert, und stattdessen den Firebird-Tarball von firebirdsql.org verwendet (der sich in /opt/firebird/ installiert)
- das Ganze auf einem anderen Debian AMD64-System probiert
- als UDF habe ich sowohl das UDF von Synerpy, als auch das von http://freeadhocudf.org/ ausprobiert.

Ich habe eine moderne GLIBC:

Code: Alles auswählen

dpkg -l libc6

-> libc6 Version 2.13-24
und AMD64-Architektur und Firebird 2.5.1, also verwende ich dieses UDF:

Code: Alles auswählen

  cp FreeAdhocUDF_FB2x64.so /opt/firebird/UDF/FreeAdhocUDF.so

Es ist aber, als ob die FreeAdhoc-Datei gar nicht existierte. Entferne ich die FreeAdhocUDF.so aus dem UDF/-Verzeichnis, so ist die Fehlermeldung genau dieselbe,
Die Rechte der FreeAdhocUDF.so habe ich auch versuchsweise auf "gefährlich" (chmod 777) gesetzt; zudem habe ich in der firebird.conf - Datei den Parameter
UdfAccess = Full
gesetzt, um hier Fehler auszuschließen.

Jetzt ist jede Idee äußerst willkommen. Ich stecke erstmal fest
Ruben

[miboe]

Eine vielleicht blöde Frage, aber haben Sie nach dem Kopieren der UDF auch den Firebird-Server neu gestartet?

Gruß
Michael

[reberg]

Nein, so richtig blöd ist die Frage nicht aber ja, den habe ich neugestartet.

[miboe]

Sind der User unter dem Firebird läuft und der Besitzer der UDF gleich? Ich hatte mal ein wüstes Problem durch AppArmor bei einer ganz anderen Anwendung, weil Prozess und Datei nicht dem gleichen User zugeordnet waren. Nicht das das so was völlig verrücktes ist ...

Gruß
Michael

[reberg]

Mit der Version von FreeAdhocUDF.org hats jetzt geklappt.
Warum es jetzt ging und vorher nicht, ist leider nicht sicher
Ich vermute tatsächlich, es war ein Rechteproblem. Nicht unbedingt bei der FreeAdhocUDF, vielleicht lags auch bei den dort referenzierten "icu"-Dateien

siehe:
http://freeadhocudf.org/dokumentation_d ... u_icu.html

Der Sache werde ich demnächst zu einer besseren Tageszeit nachgehen.
Außerdem ist mir unklar, warum es mir bei der FreeAdhocUDF.so von der Synerpy-Seite nicht gelungen ist - nur mit der Version von FreeAdhocUDF.org.

Die von Synerpy heruntergeladene FreeAdhocUDF_FB2x64.so ist
1.kleiner
2.hat offenbar weniger Abhängigkeiten; insbesondere sind die *FAU.so.* - Dateien hier offenbar nicht bekannt.
Ist das richtig so ? Vielleicht habe ich da was mißverstanden oder übersehen.

Zum Vergleich, die Abhängigkeiten der beiden FreeAdhocUDF.so-Dateien:

Code: Alles auswählen

root@Hagrid:/opt/firebird/UDF# ldd FreeAdhocUDF.so.vonSynerpy 
	linux-vdso.so.1 =>  (0x00007fff5adff000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbfb886a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbfb84e3000)
	libib_util.so => /usr/lib/x86_64-linux-gnu/libib_util.so (0x00007fbfb82e0000)
	libfbclient.so.2 => /usr/lib/x86_64-linux-gnu/libfbclient.so.2 (0x00007fbfb7ff7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fbfb8d26000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbfb7cf0000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbfb7ad9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbfb78d5000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbfb76b9000)
root@Hagrid:/opt/firebird/UDF# ldd FreeAdhocUDF.so.vonFAU.org 
	linux-vdso.so.1 =>  (0x00007fffa8dff000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f641be96000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f641bb0f000)
	libib_util.so => /usr/lib/x86_64-linux-gnu/libib_util.so (0x00007f641b90c000)
	libicudataFAU.so.44 => not found
	libicui18nFAU.so.44 => not found
	libicuucFAU.so.44 => not found
	libfbclient.so.2 => /usr/lib/x86_64-linux-gnu/libfbclient.so.2 (0x00007f641b622000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f641c35a000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f641b31b000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f641b104000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f641af00000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f641ace4000)

(Das "not found" taucht nur bei der Version von FreeAdhocUDF.org auf, und wird behoben wie unter
http://freeadhocudf.org/dokumentation_d ... u_icu.html
beschrieben.)

Wer ähnlichen Ärger hat, hier noch zum Vergleich das lib/ - Verzeichnis (/opt/firebird/lib/), mit dem es schließlich geklappt hat:

Code: Alles auswählen

/opt/firebird/lib# ls -al
total 31344
drwxr-xr-x  2 root root     4096 May 17 22:20 .
drwxr-xr-x 12 root root     4096 May 15 13:58 ..
-rwxr-x---  1 root root     2048 May 17 22:20 create_icu-symlinks_for_using.sh
lrwxrwxrwx  1 root root       16 Oct  1  2011 libfbclient.so -> libfbclient.so.2
lrwxrwxrwx  1 root root       20 Oct  1  2011 libfbclient.so.2 -> libfbclient.so.2.5.1
-rwxr-xr-x  1 root root   853496 Oct  1  2011 libfbclient.so.2.5.1
-rwxr-xr-x  1 root root     4504 Oct  1  2011 libib_util.so
-rwxrwxr-x  1 root root 14943512 May 17 22:17 libicudataFAU.so.44.2
lrwxrwxrwx  1 root root       18 Oct  1  2011 libicudata.so -> libicudata.so.30.0
lrwxrwxrwx  1 root root       18 Oct  1  2011 libicudata.so.30 -> libicudata.so.30.0
-rwxr-xr-x  1 root root  1569488 Oct  1  2011 libicudata.so.30.0
-rwxrwxr-x  1 root root  7934424 May 17 22:17 libicui18nFAU.so.44.2
lrwxrwxrwx  1 root root       18 Oct  1  2011 libicui18n.so -> libicui18n.so.30.0
lrwxrwxrwx  1 root root       18 Oct  1  2011 libicui18n.so.30 -> libicui18n.so.30.0
-rwxr-xr-x  1 root root   542920 Oct  1  2011 libicui18n.so.30.0
-rwxrwxr-x  1 root root   210073 May 17 22:17 libicuioFAU.so.44.2
-rwxrwxr-x  1 root root  5065728 May 17 22:17 libicuucFAU.so.44.2
lrwxrwxrwx  1 root root       16 Oct  1  2011 libicuuc.so -> libicuuc.so.30.0
lrwxrwxrwx  1 root root       16 Oct  1  2011 libicuuc.so.30 -> libicuuc.so.30.0
-rwxr-xr-x  1 root root   936024 Oct  1  2011 libicuuc.so.30.0

... und das UDF/ - Verzeichnis:

Code: Alles auswählen

/opt/firebird/UDF# ls -al
total 720
drwxr-xr-x  2 root root   4096 May 17 22:23 .
drwxr-xr-x 12 root root   4096 May 15 13:58 ..
-rwxr-xr-x  1 root root  19288 Oct  1  2011 fbudf.so
-rw-r--r--  1 root root   7112 Oct  1  2011 fbudf.sql
-rwxrwxr-x  1 root root 225554 May 17 22:23 FreeAdhocUDF.so
(...)
-rw-r--r--  1 root root  19170 Oct  1  2011 ib_udf2.sql
-rwxr-xr-x  1 root root  12176 Oct  1  2011 ib_udf.so
-rw-r--r--  1 root root  18525 Oct  1  2011 ib_udf.sql

... und der Server läuft unter User "firebird", den gbak-Prozess hatte ich als root gestartet.

So, jetzt erstmal Nachtruhe und Vielen Dank.
Ruben