EDICIóN GENERAL

Google ignora Windows y lanza su herramienta de edición de video VR para Linux y Mac [en]

#12
¿Que puedes tener aplicaciones de distintos sistemas operativos coexistiendo con un mismo núcleo de sistema? Sí, es posible, ¿y qué? También puedes ejecutar aplicaciones de Windows mediante Wine y eso no significa que estés ejecutando Windows en un sistema GNU-Linux o que dichas aplicaciones estén diseñadas para GNU-Linux.

No te ha aclarado nada puesto que todo lo que está enlazado con la Glibc está diseñado para GNU. Lo de diferenciar enlazado dinámico y estático es de traca. Si enlazas con GNU tu programa está diseñado para GNU, da igual si es estáticamente o dinámicamente. Si usas GNU C tu programa está diseñado para GNU ... y así con cualquier cosa que utilice las API de GNU. El sufijo {/,-,+}Linux es necesario para diferenciar qué partes de la API de GNU están disponibles.

Que piensen lo que quieran pero un kernel por sí mismo no vale nada. Sin una biblioteca de tiempo de ejecución que gestione la memoria, almacenamiento temporal y otros ... no tienes sistema operativo.
cc #14
#17 me ha aclarado bastante mas de lo que piensas otra cosa es que vayas de sobrado y no te des cuenta
#25
A mí lo que me parece es que estás desinformado.
#27 es que ni siquiera te he preguntado jajaja anda se más humilde y si hay alguien que aporta algo que a otra persona le puede ser de ayuda no seas tan crio de picarte. :palm:
#29
Tampoco le preguntaste al otro. La otra persona no ha aportado nada que ya dijera yo. Lo que dices está muy feo.
#30 simplemente he leido su comentario y al hacerlo me ha aclarado algo que siempre tuve duda, tu me has soltado una retaila que no tiene nada que ver con ella y si, a ti ni siquiera te he mencionado.
#31
Para leer su comentario antes has tenido que leer el mío en el que ya mencionaba las cosas que él decía.
#16 #17 Creo que confundes GNU con la librería estándar de C. No existe una "API GNU", como mucho algunas extensiones de GNU a la librería estándar. Pero el 99% de los programas compilados para la libc de GNU funcionarían perfectamente enlazándolos con cualquier otra implementación de la libc.
#28
Sí que existe una API de GNU. La biblioteca estándar de GNU tiene múltiples extensiones y comportamientos diferentes para funciones como malloc. El mismo estándar de C de GNU difiere del estándar ISO C. De hecho el ISO C se alimenta del estándar GNU C. El propio Linux está pensado para ser compilado usando la API del C de GNU, cuya implementación de referencia es la de GCC e imitada por Clang.

Precisamente POSIX fue una propuesta de GNU (Richard M. Stallman).

Así que sí, si estás enlazado con la Glibc o escrito en GNU C o compilado con herramientas de GNU, es que estás diseñado para la API de GNU. Eso no excluye que no esté diseñado para otras API.
#34
Luego está también el tema de la ABI, caso en el cual todos imitan la de GCC ... así que si fuera por eso todo sería GNU pero supongo que eso ya no gusta.

Extensiones GNU C: gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions
Extensiones sólo para GNU C++: gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html#C_002b_002b-
ABI de GNU:
* gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
* gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

Explicaciones acerca de la ABI: en.wikipedia.org/wiki/Application_binary_interface
* Convención para llamadas a procedimientos
** en.wikipedia.org/wiki/Calling_convention
** Arquitectura x86 dispone de múltiples formas. En el mundo POSIX actual se utiliza la de GCC (GNU): en.wikipedia.org/wiki/X86_calling_conventions
* Formato del binario. Aunque hay un estándar, el ELF, si usas GNU ld o gold el binario tiene ciertas extensiones con información adicional, útiles para depurar o modificar el comportamiento a la hora de buscar bibliotecas: en.wikipedia.org/wiki/Rpath Gracias al Rpath configurado por GNU ld puedes modificar en un sistema GNU-Linux el archivo /etc/ld.so.conf con rutas adicionales para bibliotecas. Siempre habrá otros que lo imiten para ser compatibles con GNU.
* Cómo hacer las llamadas a sistema. La GNU libc provee facilidades para realizar llamadas a sistema mediante la función syscall().
#45
El GNU C es implementado por GNU y nadie más. Si otros lo imitan entonces también son sistemas GNU.
De hecho la convención de la ABI de paso de parámetros es la de GNU (GCC).

cc #47.
#46 Todo eso que enumeras son estándares, que son implementados por infinidad de librerías distintas de la libc de GNU. Y sí, claro que funcionarían perfectamente con otra implementación. Véase, por ejemplo, la versión para OpenBSD de muchos programas GPL, que también usan esas APIs pero funcionan perfectamente con la implementación propia de OpenBSD (o de FreeBSD, o de NetBSD...).

cc #34
#47
Pues entonces me parece una tontería decir que está hecho para macOS o GNU-Linux.
Basta con decir que funciona con POSIX y Windows y ya está :roll:
#49 Exacto. Si tú haces un programa para POSIX te va a funcionar en cualquier sistema operativo Unix decente sólo con recompilarlo. Lo de GNU/Linux se refiere a la suma del kernel de Linux y las herramientas del sistema de GNU (bash, gcc, grep, etc).
#50
La realidad es que es imposible ser POSIX compatible únicamente puesto que siempre dependerás de cosas específicas del sistema operativo sobre el que se vaya a ejecutar la aplicación.

GNU-Linux es Linux junto con la biblioteca de tiempo de ejecución de GNU, las utilidades nucleicas de GNU (coreutils), las utilidades binarias de GNU (binutils) y un largo etcétera entre los que se incluye el dialecto de C de GNU. El uso de cualquiera de ellos convierte al programa en diseñado para ser compatible con GNU.

Si se llama biblioteca de tiempo de ejecución de GNU (GNU C runtime library) es por algo :roll:
Y es que dispone de funcionalidad específica de GNU y que si eres compatible con GNU eres incompatible con otros SOs salvo que lo hagas multiplataforma y tengas código que abstraiga todas las particularidades para poder explotar al 100% cada SO. La biblioteca de tiempo de ejecución de GNU realiza operaciones que otras bibliotecas de tiempo de ejecución no realizan.
Una comparación con algunas cosas: www.etalabs.net/compare_libcs.html

Con la GNU C runtime library también se incluye GNU ld, el cargador de binarios ejecutables y bibliotecas. Por cierto, dlopen() se incluyó en POSIX 2001 después de llevar bastante tiempo en la GNU C runtime library.
POSIX.1-2001 describes dlclose() and dlopen(). The dlmopen() function
is a GNU extension.

The RTLD_NOLOAD, RTLD_NODELETE, and RTLD_DEEPBIND flags are GNU exten‐
sions; the first two of these flags are also present on Solaris.


Luego está también el tema de la ABI, caso en el cual todos imitan la de GCC ... así que si fuera por eso todo sería GNU pero supongo que eso ya no gusta.

Extensiones GNU C: gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions
Extensiones sólo para GNU C++: gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html#C_002b_002b-
ABI de GNU:
* gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
* gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

Explicaciones acerca de la ABI: en.wikipedia.org/wiki/Application_binary_interface
* Convención para llamadas a procedimientos
** en.wikipedia.org/wiki/Calling_convention
** Arquitectura x86 dispone de múltiples formas. En el mundo POSIX actual se utiliza la de GCC (GNU): en.wikipedia.org/wiki/X86_calling_conventions
* Formato del binario. Aunque hay un estándar, el ELF, si usas GNU ld o gold el binario tiene ciertas extensiones con información adicional, útiles para depurar o modificar el comportamiento a la hora de buscar bibliotecas: en.wikipedia.org/wiki/Rpath Gracias al Rpath configurado por GNU ld puedes modificar en un sistema GNU-Linux el archivo /etc/ld.so.conf con rutas adicionales para bibliotecas. Siempre habrá otros que lo imiten para ser compatibles con GNU.
* Cómo hacer las llamadas a sistema. La GNU libc provee facilidades para realizar llamadas a sistema mediante la función syscall().
#28 Que yo sepa desde sus inicios Linus Tolvard reconoció haber usado el compilador de GNU y que fue esa una de las causas que le llevó a poner la linencia GPL al cual, el código del Kernel esta ligado. www.gnu.org/software/libc/libc.html
These libraries provide critical APIs including ISO C11, POSIX.1-2008, BSD, OS-specific APIs and more. These APIs include such foundational facilities as open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit and more.
¿Así que las APIS criticas funcionarían perfectamente con otra implementacion de libc? Claro que no usen ventanas, login, cifrado, abrir archivos, etc. Cuéntame más.... :shit:
CC #15

menéame