Diferentes formas de especificar bibliotecas a gcc/g ++

Question

Me gustaría saber si hay alguna diferencia sustancial en la especificación de bibliotecas (tanto compartidas como estáticas) a gcc/g ++ de las dos formas siguientes (CC puede ser g ++ o gcc)

CC -o output_executable /path/to/my/libstatic.a /path/to/my/libshared.so source1.cpp source2.cpp ... sourceN.cpp 

vs

CC -o output_executable -L/path/to/my/libs -lstatic -lshared source1.cpp source2.cpp ... sourceN.cpp 

sólo puedo ver una diferencia importante es que pasando directamente el nombre de biblioteca especificada completamente haría para un mayor control en la elección de versiones estáticas o dinámicas, pero sospecho que hay algo más adelante que puede tener efectos secundarios sobre cómo el ejecu la tabla está construida o se comportará en tiempo de ejecución, ¿estoy en lo cierto?

Andrea.

Answer 1

Ok, puedo responder yo mismo basándose en algunos experimentos y una lectura más profunda de la documentación gcc:

De la documentación gcc: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

[...] El enlazador se encarga de un archivo de almacenamiento en los escaneos a través de él para miembros que definen símbolos que hasta ahora se han referenciado pero no definido. Pero si el archivo que se encuentra es un archivo de objeto ordinario, está vinculado de la manera habitual. La única diferencia entre el uso de una opción -l y especificar un nombre de archivo es que rodea -l biblioteca con lib' and .a' y búsquedas varios directorios

Esto responde en realidad también a la duda relacionada sobre la tercera opción de especificar directamente los archivos objeto en la línea de comando gcc (es decir, en ese caso todo el código en los archivos objeto se convertirá en parte del ejecutable final, mientras se utilizan los archivos, solo se extraerán los archivos objeto que realmente se necesitan).