Servus! Ich habe gestern ewig versucht, ein neues fftw-xxx (mpi,threads,devel...) RPM zu bauen. Dazu habe ich das SuSE SPEC (fftw-2.1.3) abgewandelt, denn ich wollte nicht gegen MPICH (was haufenweise Probleme macht), sondern gegen LAM (was SuSE netterweise ohne shared-Libraries ausliefert - also musste ich es auch neu bauen) kompilieren. Wenn ich alles per Hand mache (configure/make...), funktioniert es auch, nur im RPM werden keine shared Libraries erstellt. Die Option --enable-shared ist aber gesetzt und wird auch benutzt... Was läuft da falsch ? Eine Besonderheit bei diesem RPM ist, dass 2mal kompiliert wird, um auch noch die single-precision Version zu bauen, das macht es so schwer einfach checkinstall zu nehmen. Wie gesagt, wenn ich die configure-Aufrufe aus dem Log-File nehme, geht alles glatt. Nur will ich die entsprechenden SuSE-kompatiblen RPMs haben, sonst muss ich wieder alle darauf aufbauenden Pakete verbiegen. Mathias
Hallo, Am Wed, 16 Feb 2005, Mathias Weigt schrieb:
Ich habe gestern ewig versucht, ein neues fftw-xxx (mpi,threads,devel...) RPM zu bauen. Dazu habe ich das SuSE SPEC (fftw-2.1.3) abgewandelt, denn ich wollte nicht gegen MPICH (was haufenweise Probleme macht), sondern gegen LAM (was SuSE netterweise ohne shared-Libraries ausliefert - also musste ich es auch neu bauen) kompilieren.
Wenn ich alles per Hand mache (configure/make...), funktioniert es auch, nur im RPM werden keine shared Libraries erstellt. Die Option --enable-shared ist aber gesetzt und wird auch benutzt... Was läuft da falsch ?
Zeig mal den configure Aufruf, der tatsaechlich verwendet wird. -dnh -- How do girls get minks? Same way minks get minks. -- unk.
Am Mittwoch, 16. Februar 2005 18:01 schrieb David Haller:
Hallo,
Am Wed, 16 Feb 2005, Mathias Weigt schrieb:
Ich habe gestern ewig versucht, ein neues fftw-xxx (mpi,threads,devel...) RPM zu bauen. Dazu habe ich das SuSE SPEC (fftw-2.1.3) abgewandelt, denn ich wollte nicht gegen MPICH (was haufenweise Probleme macht), sondern gegen LAM (was SuSE netterweise ohne shared-Libraries ausliefert - also musste ich es auch neu bauen) kompilieren.
Wenn ich alles per Hand mache (configure/make...), funktioniert es auch, nur im RPM werden keine shared Libraries erstellt. Die Option --enable-shared ist aber gesetzt und wird auch benutzt... Was läuft da falsch ?
Zeig mal den configure Aufruf, der tatsaechlich verwendet wird. Das ist aus dem Logfile (die + muss man sich wegdenken und alles ist dann in einer Zeile):
+ CFLAGS='-O2 -g -march=i586 -mcpu=i686 -fmessage-length=0 -L/opt/lam/lib -I/opt/lam/include ' + MPICC=/opt/lam/bin/mpicc + ./configure --prefix=/usr --libdir=/usr/lib --enable-shared --enable-type-prefix --enable-threads --enable-mpi --infodir=/usr/share/info --enable-i386-hacks Trotzdem meint configure dann: checking whether to build shared libraries... no Ich probiere es noch mal mit genau diesem Aufruf (vielleicht war meine Reihenfolge der Schalter anders) Mathias
Am Donnerstag, 17. Februar 2005 09:12 schrieb Mathias Weigt:
Am Mittwoch, 16. Februar 2005 18:01 schrieb David Haller:
Zeig mal den configure Aufruf, der tatsaechlich verwendet wird.
Das ist aus dem Logfile (die + muss man sich wegdenken und alles ist dann in einer Zeile):
+ CFLAGS='-O2 -g -march=i586 -mcpu=i686 -fmessage-length=0 -L/opt/lam/lib -I/opt/lam/include ' + MPICC=/opt/lam/bin/mpicc + ./configure --prefix=/usr --libdir=/usr/lib --enable-shared --enable-type-prefix --enable-threads --enable-mpi --infodir=/usr/share/info --enable-i386-hacks
Ich hab den Unterschied gefunden, weiss aber noch nicht, warum: Aus dem Log (RPM): checking dynamic linker characteristics... no checking if libtool supports shared libraries... no checking whether to build shared libraries... no Nach dem Aufruf (identisch) per Hand: checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes Des weiteren: checking build system type... i686-suse-linux checking host system type... i686-suse-linux -- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu und: checking for a sed that does not truncate output... /usr/bin/sed checking how to recognise dependent libraries... unknown -- checking for a sed that does not truncate output... /bin/sed checking how to recognise dependent libraries... pass_all Mathias
Hallo, Am Thu, 17 Feb 2005, Mathias Weigt schrieb: [..]
Ich hab den Unterschied gefunden, weiss aber noch nicht, warum:
Aus dem Log (RPM): checking dynamic linker characteristics... no checking if libtool supports shared libraries... no checking whether to build shared libraries... no
Nach dem Aufruf (identisch) per Hand: checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes
Des weiteren: checking build system type... i686-suse-linux checking host system type... i686-suse-linux -- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu
Ok, dann kennt das configure deinen host-type nicht, sage dem rpm dann mal, dass es i686-pc-linux-gnu verwenden soll: rpmbuild -bc --target=i686-pc-linux-gnu specdatei -dnh -- "Grove giveth and Gates taketh away." - Bob Metcalfe (inventor of Ethernet) on the trend of hardware speedups not being able to keep up with software demands
Am Donnerstag, 17. Februar 2005 18:50 schrieb David Haller:
Hallo, rpmbuild -bc --target=i686-pc-linux-gnu specdatei Das hat es nicht gebracht, aber es brachte mich auf die Idee bei configure noch mal nachzuschauen. Ich habe jetzt --build=i686-pc-linux-gnu mit ins SPEC geschrieben. Das hatte den gewünschten Effekt.
Vielen Dank Mathias
participants (2)
-
David Haller
-
Mathias Weigt