LINUX.ORG.RU
решено Форум — Development  

make файлы


0

1

Всем привет!
Возник вопрос по make-файлам, который не решился просмотром info страниц. Есть необходимость скармливать компоновщику библиотеки в определенном порядке (runtime). Сейчас я это делаю так: 

 $(LD) file.o $(LD_FINALIZE)
(LD_INIT содержится в LD. По сути, надо $(LD) $(LD_INIT) file.o $(LD_FINALIZE))
а хочу так: 
 $(LD) file.o
Вопрос: не много ли я хочу? Это можно сделать?
Спасибо.

← Книги по основам работы с OpenGL
noweb, $ в чанках →
Ответ на: комментарий от Bad_ptr 
$(LD) file.o

раскрывается в 

ld ... .../crt1.o .../crti.o file.o -lc .../crtn.o
т.е. фишка в том, что file.o компонуется не последним. с LD_FINALIZE все понятно:
LD = ld .../ .../crt1.o .../crti.o
LD_FINALIZE = -lc ../crtn.o
$(LD) file.o $(LD_FINALIZE)
но можно ли сделать так, чтобы имя файла само вставлялось в середину...

kermzyxer ★
() автор топика
Ответ на: комментарий от kermzyxer

>я на асме пишу

Пофиг, когда gcc запускается с объектными файлами параметрами, он вызывает ld, линкуя их все с нужными startfiles в исполняемый файл. Не важно, на каком языке были написаны исходники, они уже всё равно скомпилированы.

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

> gcc не использую
Я его не использую для того, чтобы получались более ``чистые" исполняемые файлы. Да и зачем он, если я не использую ни сей, ни сишных макросов?

kermzyxer ★
() автор топика
Ответ на: комментарий от kermzyxer

О господи, да тут же gcc не имеет никакого отношения к сишному коду. Какие к чёрту макросы?

Если вызывать так: ‘gcc -o executable first.o second.o third.o’, то компилироваться ничего не будет, gcc всего лишь вызовет линкер ld, чтобы собрать эти объектные файлы со startfiles (crt?.o) и динамически связать с libc, т.е. то, что вы делаете с помощью ld, но без лишних параметров, которые ещё и могут быть разными в разных системах с разными тулчейнами. Более «чистые» или «грязные» исполняемые файлы не будут — чем их можно «загрязнить»?

gentoo_root ★★★★★
()
Ответ на: комментарий от kermzyxer

>Я его не использую для того, чтобы получались более ``чистые" исполняемые файлы.

gcc -nostdlib file.s

Yareg ★★★
()
Ответ на: комментарий от gentoo_root

> О господи, да тут же gcc не имеет никакого отношения к сишному коду.

gcc не имеет никакого отношения к сишному коду

Ахах! Что вы говорите? =)

Какие к чёрту макросы?

Макросы = препроцессор Си - одна из причин использовать gcc.

без лишних параметров, которые ещё и могут быть разными в разных системах с разными тулчейнами.

Да, они БУДУТ разными. Например, в дистрибутивах из разних веток. Но меня это не пугает. Потому, что курсовая. Ее нужно сдавать и забывать, а не портировать в другие дистры.

Более «чистые» или «грязные» исполняемые файлы не будут — чем их можно «загрязнить»?

readelf и System V ABI вам в руки! Поразбирайте по докам два файла - один gcc'шный, второй - свой. Увидите разницу.

Еще раз говорю.
Если уж на то пошло, то можно тупо скормить gcc ассемблерный листинг - съест.
Но я им не пользуюсь. Потому, что пишу на чистом асме.

kermzyxer ★
() автор топика
Ответ на: комментарий от kermzyxer

> О господи, да тут же gcc не имеет никакого отношения к сишному коду.

> gcc не имеет никакого отношения к сишному коду

Ахах! Что вы говорите? =)

сорри, вот слова ``тут" я как-то не заметил.

По поводу gcc и исполняемых файлов, которые он выдает:

me@thinkpad-x220:~/trash$ gcc -v test.s
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-4' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,o
bj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib
 --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gn
u --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --ena
ble-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu                                                                       
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-4) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 as --64 -o /tmp/ccKwbnzb.o test.s
COMPILER_PATH=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gn
u/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/                                                              
LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux
-gnu/                                                                                                                                                                 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/collect2 --build-id --no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linu
x-x86-64.so.2 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../crt1.o /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../crti.o /usr/lib/x86_64
-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../..
 -L/usr/lib/x86_64-linux-gnu /tmp/ccKwbnzb.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/x86_64-linux-gnu/gcc/x86_64
-linux-gnu/4.6.1/crtend.o /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../crtn.o
Никаких секретов нет =)
Наверное, на него можно как-то повлиять, но все и так работает: 
me@thinkpad-x220:~/trash$ make
as  -o test.o test.s
ld -m elf_x86_64 -dynamic-linker /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o -lc /usr/lib/x86_64-linux
-gnu/crtn.o -o test test.o                                                                
rm *.o

kermzyxer ★
() автор топика
Ответ на: комментарий от kermzyxer

Ахах! Что вы говорите? =)

Вообще-то, именно так и есть. gcc — всего лишь враппер для запуска других программ, которые преобразуют в ассемблер (cc1), преобразуют ассемблерный код в объектный файл (as), линкуют объектные файлы в исполняемый (ld) и т.п. Бинарник размером 8 KiB не может это всё делать, хотя бы так.

Макросы = препроцессор Си - одна из причин использовать gcc.

Ещё раз повторюсь: если вызывать gcc так, как я написал, то не будет препроцессирования, компиляции и ассемблирования, а будет только линковка с помощью ld. Макросы тут вообще ни при чём, т.к. на этапе линковки объектных файлов их некуда прилепить, а парсятся они препроцессором. Препроцессор же не будет вызываться, т.к. его просто не над чем выполнять (не над объектными файлами же).

Т.е. в данном случае gcc просто вызовет линкер ld, чтобы слинковать объектные файлы с startfiles и libc, что, собственно, и нужно. Вот полный выхлоп:

# gcc a.o -v
Используются внутренние спецификации.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.5.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.5.3/lto-wrapper
Целевая архитектура: i686-pc-linux-gnu
Параметры конфигурации: /tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.5.3/python --enable-checking=release --disable-libgcj --with-arch=i686 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r1 p1.0, pie-0.4.5'
Модель многопоточности: posix
gcc версия 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) 
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/i686-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/:/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.5.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.5.3 -L/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../.. a.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/crtend.o /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../crtn.o

# ldd a.out
        linux-gate.so.1 =>  (0xb782b000)
        libc.so.6 => /lib/libc.so.6 (0xb7694000)
        /lib/ld-linux.so.2 (0xb780f000)

Хоть там и было -lgcc и -lgcc_s, но благодаря --as-needed с ними не было динамического связывания. Поэтому вызов gcc для линковки в этом случае ничем не хуже, а ещё и лучше переносимостью.

Да, они БУДУТ разными. Например, в дистрибутивах из разних веток. Но меня это не пугает. Потому, что курсовая. Ее нужно сдавать и забывать, а не портировать в другие дистры.

Вот не заработает на компе у препода — будет +1 ССЗБ.

Если уж на то пошло, то можно тупо скормить gcc ассемблерный листинг - съест. Но я им не пользуюсь. Потому, что пишу на чистом асме.

Дык пиши на «чистом асме» и собирай с gcc, он его «грязным асмом» не делает.

readelf и System V ABI вам в руки!

Вот выхлоп ‘readelf -l’ из моего бинарника, скомпилированного и слинкованного gcc со смешанным кодом на асме и си:

Elf file type is EXEC (Executable file)
Entry point 0x10000c
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00100000 0x00100000 0x015fb 0x015fb R E 0x1000
  LOAD           0x002600 0x00102600 0x00102600 0x00000 0x01010 RW  0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text .rodata 
   01     .bss 
   02

Ничего лишнего там нет, поэтому не надо так бояться gcc.

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

>gcc ... file.o
Ага +1.
Тоже сначала делал через ld, а потом какие-то ошибки повылазили :-)), забил и передаю всю эту грязную работу на gcc.

Bad_ptr ★★★★★
()
Ответ на: комментарий от gentoo_root

> поэтому не надо так бояться gcc
Я его ни сколько не боюсь, а даже наоборот. Обычно я им и пользуюсь, просто сегодня я пишу на асме и у меня день низкоуровнего софта.

Вот выхлоп ‘readelf -l’ из моего бинарника, скомпилированного и слинкованного gcc со смешанным кодом на асме и си

Не маловато секций? :)
Почему такой странный entry point?

kermzyxer ★
() автор топика
Ответ на: комментарий от Bad_ptr

Ну какие ошибки там могут вылезти? Скорее gcc перестанет работать, чем стандартнейшие unix-утилиты =) Видимо, тормозил где-то ))

kermzyxer ★
() автор топика
Ответ на: комментарий от kermzyxer

>Не маловато секций? :) Почему такой странный entry point?

Это собрано с -ffreestanding и -nostartfiles и предназначено для запуска из grub по протоколу multiboot.

gentoo_root ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Книги по основам работы с OpenGL
Development
noweb, $ в чанках →