я нашел один вариант __attribute__((used))
но он для статических функцию

Здравствуйте, sergey2b, Вы писали:

S>я нашел один вариант __attribute__((noreturn))
S>но он для статических функцию

Можно попробовать собрать единицу трансляции в режиме, когда все функции не раскладываются по отдельным секциям, а кладутся в одну. При этом в единице трансляции должно быть что-то, что гарантированно используется. Такая опция есть у всех известных мне компиляторов.

Другой вариант — ковырять компилер-специфик прагмы и прочие директивы.

Ты, как я понимаю, собираешь DLL/SO? Если так, то наверно надо явно указать, что ты хочешь это экспортировать. Для DLL это можно сделать. Для линупса с их SO-шками, в которых обычно торчит наружу всё, что есть — тут да, надо подумать. Можно попробовать замутить какие-0то зависимости, которые компилер/линкер не смогут разрулить, но это не точно.

Для экзешника вроде это мало имеет смысла, если ты конечно не собираешь экзешник, экспортирующий какие-то функции, которые кто-то собирается импортировать — например, зависимые от загружающего их экзешника DLLки.

ЗЫ А __attribute__((noreturn)) — это совсем из другой оперы, и то, что они сейчас линкуются безусловно — это просто баг/тупизна линкера, и на которую закладываться не стоит

Здравствуйте, удусекшл, Вы писали:

У>ЗЫ А __attribute__((noreturn)) — это совсем из другой оперы, и то, что они сейчас линкуются безусловно — это просто баг/тупизна линкера, и на которую закладываться не стоит

спасибо за ответ
я компилирую под linux

я там описался атрибут должен быть __attribute__((used))

Здравствуйте, sergey2b, Вы писали:

S>я нашел один вариант __attribute__((noreturn))
S>но он для статических функцию

Вы уверены что компилятор удалет именно символ, а всю единицу трансляции?

// unused_foo.h
void unused_foo();
static auto dont_remove_unused_foo = & unused_foo;

// unused_foo.cpp
void unused_foo()
{
    std::cout<<"Foo"<<std::endl;
}

Разумеется unused_foo.h должен быть включен куда-то, что не будет удалено линковщиком.
Наверное, можно использовать inline вместо static в современных версиях стандарта.

Здравствуйте, sergey2b, Вы писали:

У>>ЗЫ А __attribute__((noreturn)) — это совсем из другой оперы, и то, что они сейчас линкуются безусловно — это просто баг/тупизна линкера, и на которую закладываться не стоит

S>спасибо за ответ
S>я компилирую под linux

S>я там описался атрибут должен быть __attribute__((used))


Ну, это больше похоже на правду. В принципе, это имхо старый добрый атрибут, который никуда не денется в ближайшие лет 10. В чем тогда твоя проблема?

Здравствуйте, удусекшл, Вы писали:



У>Ну, это больше похоже на правду. В принципе, это имхо старый добрый атрибут, который никуда не денется в ближайшие лет 10. В чем тогда твоя проблема?

есть кросплатформенная библиотека которая нормально собраеться mingw64
собираю с тех же исходников gcc под linux

генерирую несколько .a
при линковки с приложением появляються сообщение
xxx.c:63: undefined reference to `aa_parse'

при том что функция вызываеться из нескольких других функций библиотеки

Здравствуйте, Chorkov, Вы писали:

C>Здравствуйте, sergey2b, Вы писали:

S>>я нашел один вариант __attribute__((noreturn))
S>>но он для статических функцию

C>Вы уверены что компилятор удалет именно символ, а всю единицу трансляции?

есть кросплатформенная библиотека которая нормально собраеться mingw64
собираю с тех же исходников gcc под linux

генерирую несколько .a
при линковки с приложением появляються сообщение
xxx.c:63: undefined reference to `aa_parse'

при том что функция вызываеться из нескольких других функций библиотеки

Здравствуйте, sergey2b, Вы писали:

У>>В чем тогда твоя проблема?

S>есть кросплатформенная библиотека которая нормально собраеться mingw64
S>собираю с тех же исходников gcc под linux

S>генерирую несколько .a
S>при линковки с приложением появляються сообщение
S>xxx.c:63: undefined reference to `aa_parse'

S>при том что функция вызываеться из нескольких других функций библиотеки


Хм. Слишком общее описание, тут может быть всё, что угодно, начиная с того, что код может быть исключен препроцессором, заканчивая соглашениями о вызове и какими-то завязками на манглинг имен конкретного компилера. Я бы начал с того, что постарался бы точно идентифицировать проблему

сочувствую вашему и всем остальным американским работодателями
если все остальные кандидаты такого же уровня как и вы

Здравствуйте, sergey2b, Вы писали:

S>генерирую несколько .a
S>при линковки с приложением появляються сообщение
S>xxx.c:63: undefined reference to `aa_parse'
S>при том что функция вызываеться из нескольких других функций библиотеки

Тут, похоже, про порядок линковки речь. Сначал должно идти то, что использует, а потом то, что используется. В гугле есть инфа.

Здравствуйте, reversecode, Вы писали:

R>сочувствую вашему и всем остальным американским работодателями
R>если все остальные кандидаты такого же уровня как и вы

а кому же сейчас легко

Здравствуйте, andrey.desman, Вы писали:

AD>Тут, похоже, про порядок линковки речь. Сначал должно идти то, что использует, а потом то, что используется. В гугле есть инфа.

Кстати, да. Если речь идёт про такую лучшую для всех времён и народов систему, как линупс, то там инструменты такие же, как и вся система — если не в том порядке задать либы в списке линкера, то хрен что найдётся

Здравствуйте, reversecode, Вы писали:

R>сочувствую вашему и всем остальным американским работодателями
R>если все остальные кандидаты такого же уровня как и вы

Зато там все успешные эмбедщики пишут tar на коленке за десять минут, хотя, казалось бы — где эмбед, а где tar

И умеют в алгоритмы, не парясь о тупом говне и граблях от примитивных инструментов

Здравствуйте, удусекшл, Вы писали:

У>Здравствуйте, andrey.desman, Вы писали:

AD>>Тут, похоже, про порядок линковки речь. Сначал должно идти то, что использует, а потом то, что используется. В гугле есть инфа.

У>Кстати, да. Если речь идёт про такую лучшую для всех времён и народов систему, как линупс, то там инструменты такие же, как и вся система — если не в том порядке задать либы в списке линкера, то хрен что найдётся

в моем случаи порядок задан правильно — o приложения, мои libs и потом уже сторонние библиотеки

Здравствуйте, sergey2b, Вы писали:

У>>Кстати, да. Если речь идёт про такую лучшую для всех времён и народов систему, как линупс, то там инструменты такие же, как и вся система — если не в том порядке задать либы в списке линкера, то хрен что найдётся

S>в моем случаи порядок задан правильно — o приложения, мои libs и потом уже сторонние библиотеки

Я бы не советовал бы быть таким самоуверенным, что ты всё задал как надо в нужном порядке. Это линупс, малыш, а значит — страдать должны все

Здравствуйте, sergey2b, Вы писали:

S>в моем случаи порядок задан правильно — o приложения, мои libs и потом уже сторонние библиотеки

И чем этот порядок правильный? Дело же не в принадлежности к твоим или сторонним, а в том, что на что ссылается.

Можешь попробовать архивы поместить в группу:

-( archives -)
--start-group archives --end-group
The archives should be a list of archive files. They may be either explicit file names, or -l options.
The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved.

Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.

Это опция ld, поэтому ее надо укзывать через -Wl

-Wl,--start-group -llib1 -llib2 -llib3 -Wl,--end-group

Здравствуйте, sergey2b, Вы писали:

S>в моем случаи порядок задан правильно — o приложения, мои libs и потом уже сторонние библиотеки

В твоём случай что-то пошло не так. Скорее всего проблема — в тебе, а не в системе, если ты понимаешь, о чем я. Ты пишешь под линупс, а там не система для людей, а люди для системы, а если что не так, то линупсовые набигуторы тебе быстро объяснят, что ты родился с генетическими отклонениями с руками на уровне таза

Здравствуйте, удусекшл, Вы писали:

У>Здравствуйте, sergey2b, Вы писали:

S>>в моем случаи порядок задан правильно — o приложения, мои libs и потом уже сторонние библиотеки

У>В твоём случай что-то пошло не так. Скорее всего проблема — в тебе, а не в системе, если ты понимаешь, о чем я. Ты пишешь под линупс, а там не система для людей, а люди для системы, а если что не так, то линупсовые набигуторы тебе быстро объяснят, что ты родился с генетическими отклонениями с руками на уровне таза

и что же мне теперь делать ?