Saben como se compilan los ficheros con el código fuente que trae suse en formato src.rpm. O bien donde hay algún pequeño manual. Gracias ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es
El 17/10/05, A C
Saben como se compilan los ficheros con el código fuente que trae suse en formato src.rpm.
rpmbuild
O bien donde hay algún pequeño manual.
http://www.linuxparatodos.net/geeklog/staticpages/index.php?page=como-rpmbui... esta orientado a ser utilizado con fedora/yum, pero sirve igual para lo q necesitas y mucho mas. salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
El Lunes, 17 de Octubre de 2005 05:13, A C escribió:
Saben como se compilan los ficheros con el código fuente que trae suse en formato src.rpm.
Como root: rpmbuild --rebuild nombre_paquete_src.rpm Es posible que salgan dependencias que habrá que resolver instalando las librerías o programas que te hagan falta. Cuando todo vaya bien, se habrán creado los paquetes .rpm a partir de src.rpm y estarán localizados en: /usr/src/packages/RPMS/ Ahí hay varios subdirectorios, y cada uno se corresponde con una arquitectura diferente... Según la arquitectura para la que se hayan compilado, los paquetes estarán en un subdirectorio o en otro. Un saludo.
El Lunes, 17 de Octubre de 2005 10:58, Miguel A. Casado escribió:
El Lunes, 17 de Octubre de 2005 05:13, A C escribió:
Saben como se compilan los ficheros con el código fuente que trae suse en formato src.rpm.
Como root:
rpmbuild --rebuild nombre_paquete_src.rpm
* No veo la diferencia de esta compilacion con el paquete binario ya existente, se supone que se baja uno el fuente para añadir o quitar alguna caracteristica. rpm -i paquete.src.rpm desempaquetara y colocara los fuentes en el arbol de desarrollo standard, /usr/src/packages/ cada parte en sus distintos directorios. * Una de las formulas seria, editar el fichero paquete.spec situado en /usr/src/packages/SPECS/ modificar lo que uno precise y rpmbuild -ba fichero.spec compilara con las nuevas caracteristicas dejando el rpm en el lugar que ya habeis indicado.
El Lunes, 17 de Octubre de 2005 14:25, jose maria escribió:
Como root:
rpmbuild --rebuild nombre_paquete_src.rpm
* No veo la diferencia de esta compilacion con el paquete binario ya existente, se supone que se baja uno el fuente para añadir o quitar alguna caracteristica. rpm -i paquete.src.rpm desempaquetara y colocara los fuentes en el arbol de desarrollo standard, /usr/src/packages/ cada parte en sus distintos directorios.
Tienes razón. Pero por ejemplo, cuando no funcionaban las notificaciones de KDE por haber instalado el paquete arts de SuSE (tenía algún bug...), simplemente haciendo ese rebuild del paquete src.rpm lo conseguíamos hacer funcionar: http://lists.suse.com/archive/suse-linux-s/2005-Feb/0462.html Saludos.
El Lunes, 17 de Octubre de 2005 05:13, A C escribió:
Saben como se compilan los ficheros con el código fuente que trae suse en formato src.rpm. Como root:
rpmbuild --rebuild nombre_paquete_src.rpm
* No veo la diferencia de esta compilacion con el paquete binario ya existente, se supone que se baja uno el fuente para añadir o quitar alguna caracteristica.
Sí puede haber diferencias: rpmbuild --rebuild nombre_paquete_src.rpm compila con (target i=586) Puedes hacer: rpmbuild --rebuild nombre_paquete_src.rpm --target=athlon, i686... Que se puede llegar a notar, y además, las fuentes suelen compilar contra determinadas liberías, que tú, puedes haber actualizado y el binario orignal estar compilado contra una liberías con diferente versión.
El 17/10/05, csalinux
El Lunes, 17 de Octubre de 2005 05:13, A C escribió:
Saben como se compilan los ficheros con el código fuente que trae suse en formato src.rpm. Como root:
rpmbuild --rebuild nombre_paquete_src.rpm
* No veo la diferencia de esta compilacion con el paquete binario ya existente, se supone que se baja uno el fuente para añadir o quitar alguna caracteristica.
Sí puede haber diferencias:
rpmbuild --rebuild nombre_paquete_src.rpm compila con (target i=586)
Puedes hacer:
rpmbuild --rebuild nombre_paquete_src.rpm --target=athlon, i686...
es valido lo q dices !!! ;-)
Que se puede llegar a notar,
mmm.. notar para mas !!! bien como notar para menos tambien !!!!
y además, las fuentes suelen compilar contra determinadas liberías, que tú, puedes haber actualizado y el binario orignal estar compilado contra una liberías con diferente versión.
mmm.. expliquemos un poco el tema, pues del contrario, van a iniciar una maratona de recompilacion de TODOS los rpm por aca !!! :-D el gano en recompilar un programa de 586 para athlon/pentium4, es tan minimo q en la maioria de los casos es <= 2%, se tienes suerte superara los 5% (no encuentro el link donde se mostraba algunas comparaciones en este momento, lo sinto) q (personalmente) no vale la pena hacerlo para todos los programas !!!! sinceramente, solo haria la recompilacion de un rpm, caso el mismo no venga con una caracteristica q necesito !!!! del contrario.. el tiempo q llevaras compilando cada rpm a cada nueva version, no justificara el aumento de performance de 2 segundos q el nuevo rpm tiene !!! Por ultimo, se supone q el personal q mantienen las distribuiciones son bastante inteligentes, para crear los rpms con todas las posibles optimizaciones q se sirvan a la mayoria de los mortales. salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
Victor Hugo dos Santos escribió:
Sí puede haber diferencias:
rpmbuild --rebuild nombre_paquete_src.rpm compila con (target i=586)
Puedes hacer:
rpmbuild --rebuild nombre_paquete_src.rpm --target=athlon, i686...
es valido lo q dices !!! ;-)
Que se puede llegar a notar,
mmm.. notar para mas !!! bien como notar para menos tambien !!!!
Claro, pero yo quería decir sólamente que no es lo mismo. :)
mmm.. expliquemos un poco el tema, pues del contrario, van a iniciar una maratona de recompilacion de TODOS los rpm por aca !!! :-D
OK :)
el gano en recompilar un programa de 586 para athlon/pentium4, es tan minimo q en la maioria de los casos es <= 2%, se tienes suerte superara los 5% (no encuentro el link donde se mostraba algunas comparaciones en este momento, lo sinto) q (personalmente) no vale la pena hacerlo para todos los programas !!!!
Bueno, en caso de aplicaciones "multimedia" en los AMD se puede notar a veces... y ese 2% se puede llegar a agradecer. ¿Cuándo recompilo yo? Pues cuándo da alguna dependencia... que no hay manera de resolver... a veces recompilas y va. Con algún paquete de packman me ha pasado. Y con el kssh de la SuSE 9.2. Cuando hay un bug... a veces coges ese mismo paquete de una versión superior o inferior y te encaja sin problemas en tu sistema y ya no tienes el bug. Cuando tengo que recompilar entonces sí que le doy a la opción target=Athlon..., porque ya puestos, ¿qué trabajo me cuesta? :) De todas maneras hay una distribución, que los que la usan dicen que se gana mucho rendimiento, ya que se compila ad hoc para tu sistema -hablo de Gentoo-. Está bien tu aclaración... mira que si ponemos a todo el mundo a compilar los cuatro mil paquetes de la distro :DDDDD Gracias Víctor, un saludo.
-- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-18 a las 23:51 +0200, csalinux escribió:
Está bien tu aclaración... mira que si ponemos a todo el mundo a compilar los cuatro mil paquetes de la distro :DDDDD
Si hubiera un script automático que compilara los cuatro mil sin hacer yo nada más, ya lo hubiera usado, así tardara una quincena compilando :-P ¡Vamos! X-) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVZYltTMYHG2NR9URAnCiAJ4+a+O0bEfnZtLDrQeeU/VB/tB39ACfaQdQ m9z/kYfgVZzg9xtPzTK3BTQ= =oyAo -----END PGP SIGNATURE-----
El 18/10/05, csalinux
Victor Hugo dos Santos escribió:
[...]
el gano en recompilar un programa de 586 para athlon/pentium4, es tan minimo q en la maioria de los casos es <= 2%, se tienes suerte superara los 5% (no encuentro el link donde se mostraba algunas comparaciones en este momento, lo sinto) q (personalmente) no vale la pena hacerlo para todos los programas !!!!
Bueno, en caso de aplicaciones "multimedia" en los AMD se puede notar a veces... y ese 2% se puede llegar a agradecer.
<modo exusa=on> por esto escrebi: "en la maioria de los casos" los paquetes mutimedias, hacen parte de la minoria !!!! <modo exusa=off> es cierto... por senal, esto es (era???) uno de los motivos por lo cual el software mplayer, no se puede distribuir empaquetado, ya q segun los desarolladores, para aprovechar todas las optimizaciones del programa, se deberia de compilarlo en cada una de las maquinas.. pase rapidamente por el sitio, para ver se encontraba alguna referencia a esto, pero no encontre (lo sinto), talvez ya no exista mas... talvez si !!!
¿Cuándo recompilo yo?
Pues cuándo da alguna dependencia... que no hay manera de resolver... a veces recompilas y va. Con algún paquete de packman me ha pasado. Y con el kssh de la SuSE 9.2.
Cuando hay un bug... a veces coges ese mismo paquete de una versión superior o inferior y te encaja sin problemas en tu sistema y ya no tienes el bug.
por esto es necesario selecionar/utilizar una distribuicion "decente" (como clasifica un conocido)... para q vosotro no este se preocupando de aplicar patch al sistema a diestra y sinistra... sin q los mismos sean oficialmente soportados !!!!
Cuando tengo que recompilar entonces sí que le doy a la opción target=Athlon..., porque ya puestos, ¿qué trabajo me cuesta?
:)
De todas maneras hay una distribución, que los que la usan dicen que se gana mucho rendimiento, ya que se compila ad hoc para tu sistema -hablo de Gentoo-.
mmm.. el problema, segun comentarios escuchados, es q: tu la instala y compilas los programas de acuerdo a vuestra unica y exclusiva clase de hardware y cuando hay problemas, no hay ninguna otra persona en toda internet q tenga una configuracion semejante a la tuya !!! :-) salu2 y ahora a dormir, ya son las 5:00 y acabo de terminar unos arreglos por aca !!! ;-) -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-17 a las 17:43 -0300, Victor Hugo dos Santos escribió:
mmm.. expliquemos un poco el tema, pues del contrario, van a iniciar una maratona de recompilacion de TODOS los rpm por aca !!! :-D
el gano en recompilar un programa de 586 para athlon/pentium4, es tan minimo q en la maioria de los casos es <= 2%, se tienes suerte superara los 5% (no encuentro el link donde se mostraba algunas comparaciones en este momento, lo sinto) q (personalmente) no vale la pena hacerlo para todos los programas !!!!
En algunas aplicaciones concretas si se gana: por ejemplo, en las multimedia, o aquellas que usan la CPU de manera intensiva - y la mayoría la usan bien poco, están esperando al usuario o al disco. Pero hay que aclarar un concepto. csalinux propone esto:
rpmbuild --rebuild nombre_paquete_src.rpm --target=athlon, i686...
que es lo que yo hacía también antes. Pero hay que fijarse en el manual de rpmbuild: --target PLATFORM When building the package, interpret PLATFORM as arch-vendor-os and set the macros %_target, %_target_cpu, and %_target_os accordingly. Es decir, lo que espera el comando es algo así como "i586-suse-linux", pero no "athlon" a secas. Y lo que significa lo anterior es que va a usar el fichero de macros "/usr/lib/rpm/i586-suse-linux/macros", que contiene esta linea: %optflags -O2 -g -march=i686 -mcpu=i686 Con un 686 lo cogería de /usr/lib/rpm/i686-suse-linux/macros: %optflags -O2 -g -march=i686 -mcpu=i686 /usr/lib/rpm/i486-suse-linux/macros: %optflags -O2 -g -march=i486 /usr/lib/rpm/athlon-linux/macros: %optflags -O2 -g -march=athlon Por defecto toma, creo, más o menos, lo que daría el comando "uname -m -p -o", que en mi caso es "i686 i686 GNU/Linux". Creo es parecido a lo que el "config.sub" (que viene con el configure en los fuentes a compilar) acepta. Hay que aclarar también la diferencia entre las opciones -mcpu y -march que se pasan al compilador gcc. La primera, y que es la que más frecuentemente usamos todos, el manual dice que es: `-mcpu=CPU-TYPE' Tune to CPU-TYPE everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for CPU-TYPE are: Es decir, esta opción no fija el juego de instrucciones usado, que es donde más ganancia se da. Hace un año o dos, SuSE compilaba con -mcpu=i586 o 486, pero con el juego de instrucciones del i386, el común denominador de todas las cpus. La idea es que los programas funcionen en cualquier ordenador "pc compatible". Todos los procesadores usados por nuestros PCs tienen al menos el juego de instrucciones del i386; pero sabiendo que muchos usarían maquinas mejores, se optimiza la cola de instrucciones y alguna otra cosa para el i586. El i586 es el pentium 1. Si nosotros compilamos con -mcpu=i686, estamos optimizando algunas cosas para el pentiumpro. Eso supone bastante poca mejora. Ahora bien, si tenemos un pentium4, y usamos la optimización - -march=pentium4, entonces si que usamos el juego de instrucciones específica del P-IV, y la ganancia es más apreciable. `-march=CPU-TYPE' Generate instructions for the machine type CPU-TYPE. The choices for CPU-TYPE are the same as for `-mcpu'. Moreover, specifying `-march=CPU-TYPE' implies `-mcpu=CPU-TYPE'. Pero eso no lo logramos con un simple --target pasado al rpmbuild. Tenemos que usar una de las combinaciones posibles "arch-vendor-os", y editar el fichero correspondiente para tener la optimización ideal para nuestra máquina. En mi caso yo editaría "/usr/lib/rpm/i686-suse-linux/macros" con esta linea: %optflags -O2 -g -march=pentium4 No se si habría otra manera, puede que si. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVYfZtTMYHG2NR9URAvfgAJ4ubMsZKX1O6QQAp4x2CwhKOSA+SQCfcipQ NEcdvTPWGcA3PkDt2aYo5Cw= =o1zn -----END PGP SIGNATURE-----
El Lunes, 17 de Octubre de 2005 21:46, csalinux escribió:
rpmbuild --rebuild nombre_paquete_src.rpm
* No veo la diferencia de esta compilacion con el paquete binario ya existente, se supone que se baja uno el fuente para añadir o quitar alguna caracteristica.
Sí puede haber diferencias:
rpmbuild --rebuild nombre_paquete_src.rpm compila con (target i=586)
* o i686 o i386, depende de como este construido, de ser asi en todos los paquetes, aquellos paquetes binarios i686, glibc, db, etc, los estaria bajando de optimizacion de procesador. resumiendo yo no compilo por deporte, que no quiere decir nada mas que eso en mi caso.
Puedes hacer:
rpmbuild --rebuild nombre_paquete_src.rpm --target=athlon, i686...
* Las opciones de compilacion que tu le añadas son "añadidas" , nada que ver con el comando original expuesto.
Que se puede llegar a notar, y además, las fuentes suelen compilar contra determinadas liberías, que tú, puedes haber actualizado y el binario orignal estar compilado contra una liberías con diferente versión.
* Y tambien puede no compilar y haber actualizado tambien el binario y los paquetes de bibliotecas de desarrollo y se puede llegar a notar aun mas, si se compila el paquete.src.rpm varias veces o con una mano apoyada en el chasis, a medida que el compilador le va cogiendo el gustillo al paquete ...... src de la distribucion se entiende.
jose maria escribió: > El Lunes, 17 de Octubre de 2005 21:46, csalinux escribió: > > >>>>rpmbuild --rebuild nombre_paquete_src.rpm >>>* No veo la diferencia de esta compilacion con el paquete binario ya >>>existente, se supone que se baja uno el fuente para añadir o quitar >>>alguna caracteristica. >>Sí puede haber diferencias: >> >> >>rpmbuild --rebuild nombre_paquete_src.rpm compila con (target i=586) >> > > * o i686 o i386, depende de como este construido, de ser asi en todos los > paquetes, aquellos paquetes binarios i686, glibc, db, etc, los estaria > bajando de optimizacion de procesador. resumiendo yo no compilo por deporte, > que no quiere decir nada mas que eso en mi caso. Y no. si te bajas un paquete i686.srpm y le das la orden sin "target" lo compilas para i586. > >>Puedes hacer: >> >>rpmbuild --rebuild nombre_paquete_src.rpm --target=athlon, i686... >> > > * Las opciones de compilacion que tu le añadas son "añadidas" , nada que ver > con el comando original expuesto. > >>Que se puede llegar a notar, y además, las fuentes suelen compilar >>contra determinadas liberías, que tú, puedes haber actualizado y el >>binario orignal estar compilado contra una liberías con diferente versión. > > * Y tambien puede no compilar y haber actualizado tambien el binario y los > paquetes de bibliotecas de desarrollo y se puede llegar a notar aun mas, si > se compila el paquete.src.rpm varias veces o con una mano apoyada en el > chasis, a medida que el compilador le va cogiendo el gustillo al > paquete ...... src de la distribucion se entiende. > > Muy bien tu gracieta... pero te repito... te bajas el patquete.rpm.src de la distribución o del equipo de fútbol que tu quieras y necesita compilar contra determinadas librerías que no suelen venir el el paquete src. Si no tocas nada en tu sistema... entonces SÍ TE QUEDA UN RPM, casi exactamente igual que el orignal de la distro, no queda igual, porque le faltaría la firma digital de SuSE. Los paquetes vienen firmados... no sólo por SuSE, si no también otros empaquetadores firman sus rpm, tales como Packman, etc. En tu ordenador con tu distribución puedes haber actualizado liberías, por ejemplo, o el mismísimo kernel, y solo por ejemplo, que no vengan de los repositorios oficiales de SuSE, y al compilar el paquete puede ser distinto y notarse... te apoyes en el chasis del Renault de Fernando Alonso o en el Ferrari de Michael Schumaker. Sin acritud. Un saludo.
participants (6)
-
A C -
Carlos E. R. -
csalinux -
jose maria -
Miguel A. Casado -
Victor Hugo dos Santos