[sisyphus] По поводу сборки пакетов

[sisyphus] По поводу сборки пакетов

[Igor Tertishny]

Решился я на "тяжкий труд" :-)) - собрать для Сизифа несколько очень приятных 
и полезных программ. Написал спеку, начало прошло, пошла компиляция и... 
пакет, который сам по себе прекрасно компилируется, тут выдает ошибки. Я уж и 
туда, я уж и сюда, я уж и туда - "фыг вам, господа охвыцеры..."

Может кто подскажет, что тут делать?

Re: [sisyphus] По поводу сборки пакетов

[Vitaly Lipatov]

On 12 December 2001 11:43, Igor Tertishny wrote:
> Решился я на "тяжкий труд" :-)) - собрать для Сизифа несколько очень
> приятных и полезных программ. Написал спеку, начало прошло, пошла
> компиляция и... пакет, который сам по себе прекрасно компилируется, тут
> выдает ошибки. Я уж и туда, я уж и сюда, я уж и туда - "фыг вам, господа
> охвыцеры..."
>
> Может кто подскажет, что тут делать?
Вот вот, и у меня та же проблема (см. вчерашнее Subject:LyX building здесь же)

-- 
Lav
Виталий Липатов
ФГУП "ЦНИИ Судовой Электротехники и Технологии", Санкт-Петербург
GNU! Linux! LaTeX! LyX!

Re: [sisyphus] По поводу сборки пакетов

[AVL]

On Wed, 12 Dec 2001 10:43:46 +0200
Igor Tertishny <yuda66@yandex.ru> wrote:

> Решился я на "тяжкий труд" :-)) - собрать для Сизифа несколько очень приятных 
> и полезных программ. Написал спеку, начало прошло, пошла компиляция и... 
> пакет, который сам по себе прекрасно компилируется, тут выдает ошибки. Я уж и 
> туда, я уж и сюда, я уж и туда - "фыг вам, господа охвыцеры..."
> 
> Может кто подскажет, что тут делать?

ха. я тоже геморроился с этим.

две тонкости сразу.

1) во время сборки рпм пытается исполнить еще и секцию install (для теста)
соответственно из под непривилегированного пользователя писать в /usr/* нельзя
значит пишется все в иерархию /var/temp/lkfgj875kljfd/usr/*
но там нет готовой иерархии директорий. значит надо в секции инсталл ее создать
корень для постороения тестовой установки - это переменная %buildrpmroot
т.е. в конце build можно сделать

mkdir %rpmbuildroot/usr
mkdir %rpmbuildroot/usr/bin
mkdir %rpmbuildroot/usr/sbin
....



 

2) там же обычно меняются права и владелец устанавливаемых файлов. опять не имеем права на такое.
обычно помогает "выкусывание" соответствующих опций  -u root -g root из Makefile 
это можно сделать еще в секции prep 
perl -pi -e 's|-u root -g root||g'

Re: [sisyphus] По поводу сборки пакетов

[Vitaly Lipatov]

On 12 December 2001 12:12, AVL wrote:
> две тонкости сразу.
>
> 1) во время сборки рпм пытается исполнить еще и секцию install (для теста)
> соответственно из под непривилегированного пользователя писать в /usr/*
> нельзя значит пишется все в иерархию /var/temp/lkfgj875kljfd/usr/*
Может быть это и вызывает проблемы в секции install, но
речь идет о том, что %build не проходит, поскольку ошибки происходят
при компиляции (или при линковке). На этом этапе еще нет 
/var/temp/lkfgj875kljfd/

> 2) там же обычно меняются права и владелец устанавливаемых файлов. опять не
> имеем права на такое. обычно помогает "выкусывание" соответствующих опций 
> -u root -g root из Makefile это можно сделать еще в секции prep
> perl -pi -e 's|-u root -g root||g'
Ну то же, пока до этого этапа не дойти, всё гораздо раньше обрывается :(
-- 
Lav
Виталий Липатов
ФГУП "ЦНИИ Судовой Электротехники и Технологии", Санкт-Петербург
GNU! Linux! LaTeX! LyX!

Re: [sisyphus] По поводу сборки пакетов

[Michael Shigorin]

On Wed, Dec 12, 2001 at 10:43:46AM +0200, Igor Tertishny wrote:
> Может кто подскажет, что тут делать?
script
rpm -ba
exit
less typescript

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ http://visa.chem.univ.kiev.ua/~mike/

Re: [sisyphus] По поводу сборки пакетов

[Igor Tertishny]

12 Декабрь 2001 12:15, Вы написали:
> On Wed, Dec 12, 2001 at 10:43:46AM +0200, Igor Tertishny wrote:
> > Может кто подскажет, что тут делать?
>
> script
> rpm -ba
> exit
> less typescript

Не совсем понятно... Поясните, если не трудно...

Re: [sisyphus] ðÏ ÐÏ×ÏÄÕ ÓÂÏÒËÉ ÐÁËÅÔÏ×

[Serge Skorokhodov]

Здравствуйте!

Igor Tertishny пишет, что:

IT> Решился я на "тяжкий труд" :-)) - собрать для Сизифа
IT> несколько очень приятных и полезных программ. Написал спеку,
IT> начало прошло, пошла компиляция и... пакет, который сам по
IT> себе прекрасно компилируется, тут выдает ошибки. Я уж и туда,
IT> я уж и сюда, я уж и туда - "фыг вам, господа охвыцеры..."

IT> Может кто подскажет, что тут делать?

В связи со всеми этими проблемами. Кто знает, каковы перспективы
восстановления в Linux (по крайней мере, в ALT Linux:) нормальной
ситуации: на небе один Господь, а в системе -- один компилятор
C/C++?


-- 
Serge Skorokhodov aka suralis
12.12.2001 suralis-s@mtu-net.ru

Re: [sisyphus] По поводу сборки пакетов

[Vitaly Lipatov]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On 12 December 2001 13:15, Michael Shigorin wrote:
> On Wed, Dec 12, 2001 at 10:43:46AM +0200, Igor Tertishny wrote:
> > Может кто подскажет, что тут делать?
>
> script
> rpm -ba
> exit
> less typescript
Мои попытки сборки пакета заканчиваются таким результатом (см. прил. файл).
При том, что отдельно исходники нормально компилируются.
-- 
Lav
Виталий Липатов
ФГУП "ЦНИИ Судовой Электротехники и Технологии", Санкт-Петербург
GNU! Linux! LaTeX! LyX!

[-- Attachment #2: typescript.bz2 --]
[-- Type: application/x-bzip2, Size: 12173 bytes --]

Re[2]: [sisyphus] ðÏ ÐÏ×ÏÄÕ ÓÂÏÒËÉ ÐÁËÅÔÏ×

[Serge Skorokhodov]

Здравствуйте!

Vitaly Lipatov пишет, что:

VL> On 12 December 2001 13:15, Michael Shigorin wrote:
>> On Wed, Dec 12, 2001 at 10:43:46AM +0200, Igor Tertishny wrote:
>> > Может кто подскажет, что тут делать?
>>
>> script
>> rpm -ba
>> exit
>> less typescript
VL> Мои попытки сборки пакета заканчиваются таким результатом (см. прил. файл).
VL> При том, что отдельно исходники нормально компилируются.

Ой, я совершенно не уверен, что говорю дело:) Но:

  You should update your `aclocal.m4' by running aclocal. --
  может, согласиться?

  Главнее: В конце либо не хватает каких-то объектников, либо
  порядок библиотек оказывается неверным. У Вас как Motif/LessTif
  установлены? Может, собрать исходники и конфиги от отдельной и
  rpm-сборки diff'ом прошерстить на предмет различий? Или еще -Wl
  ключик добавить в комманде:

  g++ -g -s -O2 -o lyx BufferView.o BufferView2.o BufferView_pimpl.o Bullet.o Chktex.o ColorHandler.o CutAndPaste.o DepTable.o FloatList.o Floating.o FontInfo.o FontLoader.o LColor.o LaTeX.o LaTeXFeatures.o LaTeXLog.o LyXAction.o LyXSendto.o LyXView.o MenuBackend.o Painter.o PainterBase.o Sectioning.o Spacing.o TextCache.o Timeout.o ToolbarDefaults.o UpdateInset.o Variables.o WorkArea.o bmtable.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o chset.o combox.o converter.o counters.o credits.o credits_form.o debug.o encoding.o exporter.o filedlg.o font.o form1.o gettext.o importer.o intl.o kbmap.o kbsequence.o language.o lastfiles.o layout.o layout_forms.o log_form.o lyx.o lyx_cb.o lyx_gui.o lyx_gui_misc.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfr0.o lyxfr1.o lyxfunc.o lyxlex.o lyxlex_pimpl.o lyxlookup.o lyxrc.o lyxrow.o lyxserver.o lyxvc.o main.o minibuffer.o paragraph.o print_form.o screen.o sp_form.o spellchecker.o tabular.o tabular-old.o tex-accent.o tex-strings.o texrow.o text.o text2.o tracer.o trans.o trans_mgr.o undo.o vc-backend.o vspace.o  mathed/.libs/libmathed.a insets/.libs/libinsets.a graphics/.libs/libgraphics.a ../src/frontends/xforms/.libs/libxforms.a frontends/.libs/libfrontends.a frontends/support/.libs/libfrontendsupport.a support/.libs/libsupport.a ../sigc++/.libs/libsigc.a -lforms -lXpm -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11

  чтобы все библиотеки и объектники циклически искались для
  разрешения зависимостей (вроде есть в gcc/g++ такая проблема с
  зависимостью от порядка указания библиотек)?


Вот у меня, к примеру, SciLab из изходников, "с корнем выдранных"
из .src.rpm собирается и работает, а при сборке пакета
"обламывается" на strip'анье исполнимых файлов:( И никто ничего
подсказать не может, у других-то собирается:) А я поставил из
исходников по configure/make/meke install и пользуюсь -- ведь за
поражение мишени во время пристрелки взыскание не налагается:)

-- 
Serge Skorokhodov aka suralis
12.12.2001 suralis-s@mtu-net.ru

Re: [sisyphus] По поводу сборки пакетов

[Michael Shigorin]

On Wed, Dec 12, 2001 at 12:56:54PM +0200, Igor Tertishny wrote:
> > script
> > rpm -ba /path/to/file.spec
> > exit
> > less typescript
> Не совсем понятно... Поясните, если не трудно...
Таким образом в файле typescript Вы получаете полный протокол
происходившего, соотв. легче устраивать разбор полетов.

man script :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ http://visa.chem.univ.kiev.ua/~mike/

Re: [sisyphus] По поводу сборки пакетов

[AVL]

On Wed, 12 Dec 2001 12:26:09 +0300
Vitaly Lipatov <LAV@VL3143.spb.edu> wrote:

> On 12 December 2001 12:12, AVL wrote:
> > две тонкости сразу.
> >
> > 1) во время сборки рпм пытается исполнить еще и секцию install (для теста)
> > соответственно из под непривилегированного пользователя писать в /usr/*
> > нельзя значит пишется все в иерархию /var/temp/lkfgj875kljfd/usr/*
> Может быть это и вызывает проблемы в секции install, но
> речь идет о том, что %build не проходит, поскольку ошибки происходят
> при компиляции (или при линковке). На этом этапе еще нет 
> /var/temp/lkfgj875kljfd/

еще раз.
я тоже веду речь про build
rpm -bb ytyuyt.src.rpm
в этой секции проходит тестовый инсталл. и проходит он в отличии от настоящего инсталла из под обычного юзера.

если у вас не проходит компиляция, то это очень странно. можно зайти в дир. ../build/имя_пакета и там попробовать повторить комманды секции build.
вообще тогда стоит логи предъявить.

Re: [sisyphus] По поводу сборки пакетов

[AVL]

> В связи со всеми этими проблемами. Кто знает, каковы перспективы
> восстановления в Linux (по крайней мере, в ALT Linux:) нормальной
> ситуации: на небе один Господь, а в системе -- один компилятор
> C/C++?

понятия не имею, но если господа из альтлинукса не боги на земле, то ситуация от них не зависит.
есть старый 2.95 как основа. и все остальное как попытка включить оптимизацию.
пока не получится - каша из гсс будет.

[sisyphus] Re: По поводу сборки пакетов

[Mikhail Zabaluev]

Hello Vitaly,

On Wed, Dec 12, 2001 at 02:28:21PM +0300, Vitaly Lipatov wrote:
>
> Мои попытки сборки пакета заканчиваются таким результатом
(см. прил. файл).

Какая версия gcc?

> При том, что отдельно исходники нормально компилируются.

Странно. Чем отличаются опции команды, которая выдает ошибку, в этих
двух случаях?

P.S. typescript засасывает много терминального мусора, лучше писать лог
так:

команда >build.log 2>&1

или (особенно если на удаленном сервере с кучей других задач):

nohup nice команда

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Majority, n.:
	That quality that distinguishes a crime from a law.

[sisyphus] Re: [sisyphus] По поводу сборки пакетов

[Aleksey Novodvorsky]

Serge Skorokhodov wrote:

> Здравствуйте!
>
> Igor Tertishny пишет, что:
>
> IT> Решился я на "тяжкий труд" :-)) - собрать для Сизифа
> IT> несколько очень приятных и полезных программ. Написал спеку,
> IT> начало прошло, пошла компиляция и... пакет, который сам по
> IT> себе прекрасно компилируется, тут выдает ошибки. Я уж и туда,
> IT> я уж и сюда, я уж и туда - "фыг вам, господа охвыцеры..."
>
> IT> Может кто подскажет, что тут делать?
>
> В связи со всеми этими проблемами. Кто знает, каковы перспективы
> восстановления в Linux (по крайней мере, в ALT Linux:) нормальной
> ситуации: на небе один Господь, а в системе -- один компилятор
> C/C++?
>

Туманные.
Судите сами:
-- Ядра 2.2.x  пока необходимы, именно их рекомендуется ставить на
серьезных серверах. Для их сборки нужен 2.95.3
-- 2.96 дает самый быстрый код и имеет оптимизацию под бОльшее число
архитектур, он сейчас стабилен и ялвяется основынм компилятором системы.

-- 3.0.2 ближе всех к стандарту, это самый свежий официальный релиз,
однако создает медленный в сравнение с 2.96 код.

Увы.

Rgrds, AEN

Re: [sisyphus] C/C++ compilers (was: ðÏ ÐÏ×ÏÄÕ ÓÂÏÒËÉ ÐÁËÅÔÏ×)

[Serge Skorokhodov]

Здравствуйте!

Aleksey Novodvorsky пишет, что:

<skip>

>>
>> В связи со всеми этими проблемами. Кто знает, каковы перспективы
>> восстановления в Linux (по крайней мере, в ALT Linux:) нормальной
>> ситуации: на небе один Господь, а в системе -- один компилятор
>> C/C++?
>>

AN> Туманные.

AN> Судите сами:

AN> -- Ядра 2.2.x пока необходимы, именно их рекомендуется
AN> ставить на серьезных серверах. Для их сборки нужен 2.95.3

Т.е. это чистый backward compatibility и исключительно для ядра?
И что-либо другое на нем основывать -- depricated? Дело в том,
что для Win32 gcc как раз 2.95.3-x:( Будет ли на 2.96 без проблем
компилироваться код, написанный для 2.95?

AN> -- 2.96 дает самый быстрый код и имеет оптимизацию под
AN> бОльшее число архитектур, он сейчас стабилен и ялвяется
AN> основынм компилятором системы.

AN> -- 3.0.2 ближе всех к стандарту, это самый свежий официальный
AN> релиз, однако создает медленный в сравнение с 2.96 код.

Следует ли это понимать так, что как только кодогенерация в 3.х
улучшится, будет осуществлен переход на него?

AN> Увы.

Ясно, спасибо за информацию.

-- 
Serge Skorokhodov aka suralis
12.12.2001 suralis-s@mtu-net.ru

Re: [sisyphus] C/C++ compilers (was: По поводу сборки пакетов)

[Aleksey Novodvorsky]

Serge Skorokhodov wrote:

>Здравствуйте!
>
>Aleksey Novodvorsky пишет, что:
>
><skip>
>
>>>В связи со всеми этими проблемами. Кто знает, каковы перспективы
>>>восстановления в Linux (по крайней мере, в ALT Linux:) нормальной
>>>ситуации: на небе один Господь, а в системе -- один компилятор
>>>C/C++?
>>>
>
>AN> Туманные.
>
>AN> Судите сами:
>
>AN> -- Ядра 2.2.x пока необходимы, именно их рекомендуется
>AN> ставить на серьезных серверах. Для их сборки нужен 2.95.3
>
>Т.е. это чистый backward compatibility и исключительно для ядра?
>
Еще он был нужен для OO, но 641C уже собирается gcc-3.0.2.

>
>И что-либо другое на нем основывать -- depricated?
>
Надо основываться на стандарте языка, а не на компиляторе. Хорошо 
написанный код соберется всюду.

> Дело в том,
>что для Win32 gcc как раз 2.95.3-x:( Будет ли на 2.96 без проблем
>компилироваться код, написанный для 2.95?
>
См. выше. Хороший код -- будет.

>
>
>AN> -- 2.96 дает самый быстрый код и имеет оптимизацию под
>AN> бОльшее число архитектур, он сейчас стабилен и ялвяется
>AN> основынм компилятором системы.
>
>AN> -- 3.0.2 ближе всех к стандарту, это самый свежий официальный
>AN> релиз, однако создает медленный в сравнение с 2.96 код.
>
>Следует ли это понимать так, что как только кодогенерация в 3.х
>улучшится, будет осуществлен переход на него?
>
Да. Я очень надеюсь что Master 1.1 будет собран gcc3. Если ядро не 
подкачает.

Rgrds, AEN

>
>
>AN> Увы.
>
>Ясно, спасибо за информацию.
>

Re: [sisyphus] C/C++ compilers (was: По поводу сборки пакетов)

[Maxim Penzin]

hi

On Thu, 13 Dec 2001 04:49:45 +0300
Aleksey Novodvorsky <aen@logic.ru> wrote:

> >
> Надо основываться на стандарте языка, а не на компиляторе. Хорошо 
> написанный код соберется всюду.

тут есть небольшой нюанс, так как кое-какой вполне норамальный
Ц++ код не совсем правильно интерпретируется gcc-2.95

даже если не лезть в темплейтные навороты, 
хотя plain C уже как-то не совсем ко двору,
первое, что приходит в голову

struct A { void f(){}; }; struct B: public A { int i; };

sizeof(B) ?

(большинство компилеров под ia32 считают, что должно получаться 4, а не 8 )

> >Следует ли это понимать так, что как только кодогенерация в 3.х
> >улучшится, будет осуществлен переход на него?
> >
> Да. Я очень надеюсь что Master 1.1 будет собран gcc3. Если ядро не 
> подкачает.

да фиг бы с ней с кодогенерацией, не настолько уж там все плохо.

кстати, смотрел кто-нибудь в ядро, много там мест, которые не нравиятся 3.0.2 ?
насколько я в курсе проблемы там в основном не столько с компилером, сколько с inline asm.
т.е. я давно собираю продакшен кренел при помощи гцц-3, 
а сейчас уже 3.0.2 и даже перестал молиться при этом, 
правда кернел достаточно специфический.


-- 
-- Maxim Penzin
-- icq: 3861496 - - maxp@max.irk.ru - - http://mxlab.com/maxp --

Re: [sisyphus] C/C++ compilers (was: По поводу сборки пакетов)

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

Maxim Penzin wrote
> > Надо основываться на стандарте языка, а не на компиляторе. Хорошо 
> > написанный код соберется всюду.
> 
> тут есть небольшой нюанс, так как кое-какой вполне норамальный
> Ц++ код не совсем правильно интерпретируется gcc-2.95
> 
> даже если не лезть в темплейтные навороты, 
> хотя plain C уже как-то не совсем ко двору,
> первое, что приходит в голову
> 
> struct A { void f(){}; }; struct B: public A { int i; };
> 
> sizeof(B) ?
> 
> (большинство компилеров под ia32 считают, что должно получаться 4, а не 8 )
И совершенно справедливо считают. Ищем в стандарте фразу: empty base
optimization.

-- 
Best Regards!           | Когда вам платят за работу, надо по крайней мере
Alexey Voinov           | делать вид, что вы работаете...
                        |                         Б.Виан "Осень в Пекине"
voins@voins.program.ru
voins@online.ru
vns@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [sisyphus] C/C++ compilers

[Maxim Penzin]

hi

On Thu, 13 Dec 2001 07:57:35 +0300
Alexey Voinov <voins@voins.program.ru> wrote:

> > тут есть небольшой нюанс, так как кое-какой вполне норамальный
> > Ц++ код не совсем правильно интерпретируется gcc-2.95
> > 
> > даже если не лезть в темплейтные навороты, 
> > хотя plain C уже как-то не совсем ко двору,
> > первое, что приходит в голову
> > 
> > struct A { void f(){}; }; struct B: public A { int i; };
> > 
> > sizeof(B) ?
> > 
> > (большинство компилеров под ia32 считают, что должно получаться 4, а не 8 )
>
> И совершенно справедливо считают. Ищем в стандарте фразу: empty base
> optimization.

в общем о том и спич, что gcc3 более правильный компилер, чем 2.95,
хот под него и приходится иногда что-нибудь подтачивать
согласно последней линии партии (14882).

у меня вопрос, а много ли в кернеле переделывать под gcc-3 ?



-- 
-- Maxim Penzin
-- icq: 3861496 - - maxp@max.irk.ru - - http://mxlab.com/maxp --

Re[2]: [sisyphus] C/C++ compilers (was: ðÏ ÐÏ×ÏÄÕ ÓÂÏÒËÉ ÐÁËÅÔÏ×)

[Serge Skorokhodov]

Здравствуйте!

Aleksey Novodvorsky пишет, что:

<skip>

>> И что-либо другое на нем основывать -- depricated?
>>
AN> Надо основываться на стандарте языка, а не на компиляторе.
AN> Хорошо написанный код соберется всюду.

Где ж его взять, хороший-то:) Это у других, а нам, смертным, про
свой так даже говорить суеверно:)

>> Дело в том, что для Win32 gcc как раз 2.95.3-x:( Будет ли на
>> 2.96 без проблем компилироваться код, написанный для 2.95?
>>

AN> См. выше. Хороший код -- будет.

См. выше:)

>>> -- 2.96 дает самый быстрый код и имеет оптимизацию под
>>> бОльшее число архитектур, он сейчас стабилен и ялвяется
>>> основынм компилятором системы.
>>
>>> -- 3.0.2 ближе всех к стандарту, это самый свежий официальный
>>> релиз, однако создает медленный в сравнение с 2.96 код.
>>
>> Следует ли это понимать так, что как только кодогенерация в 3.х
>> улучшится, будет осуществлен переход на него?
>>
AN> Да. Я очень надеюсь что Master 1.1 будет собран gcc3. Если ядро не 
AN> подкачает.

И вернется счастье? Будем ждать.

-- 
Serge Skorokhodov aka suralis
13.12.2001 suralis-s@mtu-net.ru

Re: [sisyphus] C/C++ compilers (was: По поводу сборки пакетов)

[Vlad Harchev]

On Thu, 13 Dec 2001, Maxim Penzin wrote:

> hi
> 
> On Thu, 13 Dec 2001 04:49:45 +0300
> Aleksey Novodvorsky <aen@logic.ru> wrote:
> 
> > >
> > Надо основываться на стандарте языка, а не на компиляторе. Хорошо 
> > написанный код соберется всюду.
> 
> тут есть небольшой нюанс, так как кое-какой вполне норамальный
> Ц++ код не совсем правильно интерпретируется gcc-2.95
> 
> даже если не лезть в темплейтные навороты, 
> хотя plain C уже как-то не совсем ко двору,
> первое, что приходит в голову
> 
> struct A { void f(){}; }; struct B: public A { int i; };
> 
> sizeof(B) ?
> 
> (большинство компилеров под ia32 считают, что должно получаться 4, а не 8 )

 В стандарте про гаранитии размеров нет ни слова (кроме того что размер
потомка будет не меньше размера предка).

 Best regards,
  -Vlad

Re[2]: [sisyphus] C/C++ compilers

[Serge Skorokhodov]

Здравствуйте!

Alexey Voinov пишет, что:

AV> Maxim Penzin wrote
>> > Надо основываться на стандарте языка, а не на компиляторе. Хорошо 
>> > написанный код соберется всюду.
>> 
>> тут есть небольшой нюанс, так как кое-какой вполне норамальный
>> Ц++ код не совсем правильно интерпретируется gcc-2.95
>> 
>> даже если не лезть в темплейтные навороты, 
>> хотя plain C уже как-то не совсем ко двору,
>> первое, что приходит в голову
>> 
>> struct A { void f(){}; }; struct B: public A { int i; };
>> 
>> sizeof(B) ?
>> 
>> (большинство компилеров под ia32 считают, что должно получаться 4, а не 8 )

AV> И совершенно справедливо считают. Ищем в стандарте фразу: empty base
AV> optimization.
    ^^^^^^^^^^^^

Мне кажется, вопрос, по меньшей мере, спорный. По крайней мере в
стандарте, вроде, ничего однозначно не говориться (на то он и
стандарт:)

Вот то, что в 2.95 разрешен доступ к private-но объявленным
внутри класса структурам -- это уже нарушение стандарта, причем
серьезное.

-- 
Serge Skorokhodov aka suralis
13.12.2001 suralis-s@mtu-net.ru

[sisyphus] gcc compilers (was Re: [sisyphus] По поводу сборки пакетов)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On Wed, Dec 12, 2001 at 03:46:36PM +0300, AVL wrote:
> > В связи со всеми этими проблемами. Кто знает, каковы перспективы
> > восстановления в Linux (по крайней мере, в ALT Linux:) нормальной
> > ситуации: на небе один Господь, а в системе -- один компилятор
> > C/C++?
> 
> понятия не имею, но если господа из альтлинукса не боги на земле, то ситуация от них не зависит.
> есть старый 2.95 как основа. и все остальное как попытка включить оптимизацию.
> пока не получится - каша из гсс будет.

В ближайшем будущем предстоит варить кашу из четырех(!) версий gcc:
+ gcc-2.95.3+
  Преимущественно для старого кода (ядро < 2.4, плохо написанные
  программы).
+ gcc-2.96 (rh)
  Действующий базовый компилятор; ближе к реализации стандартов, чем
  2.95.3, при этом в основном генерирующий быстрый и неплохой код.
+ gcc-3.0.2+
  Текущий "официальный" компилятор; еще ближе к реализации стандартов, чем
  2.96, поддерживает большее количество архитектур, однако качество кода
  оставляет желать... Да и количество хорошо написанных программ, которые
  можно этим компилятором собрать, тоже пока невелико. :( Впрочем,
  ситуация постепенно улучшается.
+ gcc-3.1 (rh)
  Компилятор будущего, примерно то же, что можно было сказать про gcc-2.96
  в момент его появления.

Скоро в Сизифе эту кашу можно будет наблюдать, и даже попробовать.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.ru/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[sisyphus] Re: gcc compilers (was Re: [sisyphus] По поводу сборки пакетов)

[Mikhail Zabaluev]

Hello Dmitry,

On Thu, Dec 13, 2001 at 11:49:14AM +0300, Dmitry V. Levin wrote:
>
> On Wed, Dec 12, 2001 at 03:46:36PM +0300, AVL wrote:
> > > В связи со всеми этими проблемами. Кто знает, каковы перспективы
> > > восстановления в Linux (по крайней мере, в ALT Linux:) нормальной
> > > ситуации: на небе один Господь, а в системе -- один компилятор
> > > C/C++?
> > 
> > понятия не имею, но если господа из альтлинукса не боги на земле, то ситуация от них не зависит.
> > есть старый 2.95 как основа. и все остальное как попытка включить оптимизацию.
> > пока не получится - каша из гсс будет.
> 
> В ближайшем будущем предстоит варить кашу из четырех(!) версий gcc:
> + gcc-2.95.3+
>   Преимущественно для старого кода (ядро < 2.4, плохо написанные
>   программы).
> + gcc-2.96 (rh)
>   Действующий базовый компилятор; ближе к реализации стандартов, чем
>   2.95.3, при этом в основном генерирующий быстрый и неплохой код.
> + gcc-3.0.2+
>   Текущий "официальный" компилятор; еще ближе к реализации стандартов, чем
>   2.96, поддерживает большее количество архитектур, однако качество кода
>   оставляет желать... Да и количество хорошо написанных программ, которые
>   можно этим компилятором собрать, тоже пока невелико. :( Впрочем,
>   ситуация постепенно улучшается.
> + gcc-3.1 (rh)
>   Компилятор будущего, примерно то же, что можно было сказать про gcc-2.96
>   в момент его появления.

Т.е. налицо такой подспудный, но устойчивый fork. Будем надеяться, что
RH не втащит обратно все то, что "помогает" собираться не совсем
корректным программам.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Beware of computerized fortune-tellers!

Re: [sisyphus] C/C++ compilers (was: По поводу сборки пакетов)

[Aleksey Novodvorsky]

Serge Skorokhodov wrote:

>
> >>
> AN> Да. Я очень надеюсь что Master 1.1 будет собран gcc3. Если ядро не
> AN> подкачает.
>
> И вернется счастье? Будем ждать.

Только не жалуйтесь потом, что у программы "со стороны" не собираются :-)

Rgrds, AEN

Re: [sisyphus] gcc compilers (was Re: [sisyphus] По поводу сборки пакетов)

[AVL]

On Thu, 13 Dec 2001 11:49:14 +0300
"Dmitry V. Levin" <ldv@alt-linux.org> wrote:

> В ближайшем будущем предстоит варить кашу из четырех(!) версий gcc:

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

я так понимаю, что предполагается определять СС= kgcc,gcc,gcc3,gcc31?

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

Re: [sisyphus] C/C++ compilers (was: По поводу сборки пакетов)

[AVL]

On Thu, 13 Dec 2001 12:50:05 +0300
Aleksey Novodvorsky <aen@altlinux.ru> wrote:

> Serge Skorokhodov wrote:
> 
> >
> > >>
> > AN> Да. Я очень надеюсь что Master 1.1 будет собран gcc3. Если ядро не
> > AN> подкачает.
> >
> > И вернется счастье? Будем ждать.
> 
> Только не жалуйтесь потом, что у программы "со стороны" не собираются :-)

будем. это карма разработчика - принимать такие упреки. :)
Алексей, не пытайтесь синтезировать свое Дао, оно этого не любит. :)

Re: [sisyphus] gcc compilers (was Re: [sisyphus] ðÏ ÐÏ×ÏÄÕ ÓÂÏÒËÉ ÐÁËÅÔÏ×)

[Serge Skorokhodov]

Здравствуйте!

Dmitry V. Levin пишет, что:

>>> В связи со всеми этими проблемами. Кто знает, каковы
>>> перспективы восстановления в Linux (по крайней мере, в ALT
>>> Linux:) нормальной ситуации: на небе один Господь, а в
>>> системе -- один компилятор C/C++?
>> 
>> понятия не имею, но если господа из альтлинукса не боги на
>> земле, то ситуация от них не зависит. есть старый 2.95 как
>> основа. и все остальное как попытка включить оптимизацию. пока
>> не получится - каша из гсс будет.

DVL> В ближайшем будущем предстоит варить кашу из четырех(!) версий gcc:
DVL> + gcc-2.95.3+
DVL>   Преимущественно для старого кода (ядро < 2.4, плохо написанные
DVL>   программы).
DVL> + gcc-2.96 (rh)
DVL>   Действующий базовый компилятор; ближе к реализации стандартов, чем
DVL>   2.95.3, при этом в основном генерирующий быстрый и неплохой код.
DVL> + gcc-3.0.2+
DVL>   Текущий "официальный" компилятор; еще ближе к реализации стандартов, чем
DVL>   2.96, поддерживает большее количество архитектур, однако качество кода
DVL>   оставляет желать... Да и количество хорошо написанных программ, которые
DVL>   можно этим компилятором собрать, тоже пока невелико. :( Впрочем,
DVL>   ситуация постепенно улучшается.
DVL> + gcc-3.1 (rh)
DVL>   Компилятор будущего, примерно то же, что можно было сказать про gcc-2.96
DVL>   в момент его появления.

DVL> Скоро в Сизифе эту кашу можно будет наблюдать, и даже попробовать.

Спасибо за как всегда исчерпывающий ответ. Остается привести
цитату из "Летучей мыши":

  - За что, за что, о Боже мой, за что, о Боже мой..:)

А когда это, по Вашему мнению, завершится? Хотя бы
ориентировочно?

-- 
Serge Skorokhodov aka suralis
13.12.2001 suralis-s@mtu-net.ru

Re[2]: [sisyphus] C/C++ compilers (was: ðÏ ÐÏ×ÏÄÕ ÓÂÏÒËÉ ÐÁËÅÔÏ×)

[Serge Skorokhodov]

Здравствуйте!

Aleksey Novodvorsky пишет, что:

AN> Serge Skorokhodov wrote:

>>
>> >>
>> AN> Да. Я очень надеюсь что Master 1.1 будет собран gcc3. Если ядро не
>> AN> подкачает.
>>
>> И вернется счастье? Будем ждать.

AN> Только не жалуйтесь потом, что у программы "со стороны" не собираются :-)

А мы не жалуемся, мы спрашиваем мнение более опытных товарищей:)
А если серьезно, то "кривость" кода с точки зрения компилятора
все же выявляется легче. А вот если собираться то будет без
ошибок, но вот потом вылетать с непонятками..:(

-- 
Serge Skorokhodov aka suralis
13.12.2001 suralis-s@mtu-net.ru

Re: [sisyphus] По поводу сборки пакетов

[Vitaly Lipatov]

On 12 December 2001 11:43, Igor Tertishny wrote:
> Решился я на "тяжкий труд" :-)) - собрать для Сизифа несколько очень
> приятных и полезных программ. Написал спеку, начало прошло, пошла
> компиляция и... пакет, который сам по себе прекрасно компилируется, тут
> выдает ошибки. Я уж и туда, я уж и сюда, я уж и туда - "фыг вам, господа
> охвыцеры..."
Как я понял, если перед %configure
поставить %undefine __libtoolize,
то configure не будет переделываться на новый лад
перед компиляцией и всё компилируется.
(У мне получилось)
-- 
Lav
Виталий Липатов
ФГУП "ЦНИИ Судовой Электротехники и Технологии", Санкт-Петербург
GNU! Linux! LaTeX! LyX!

Re: [sisyphus] C/C++ compilers (was: По поводу сборки пакетов)

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Vlad Harchev wrote
> > > Надо основываться на стандарте языка, а не на компиляторе. Хорошо 
> > > написанный код соберется всюду.
> > 
> > тут есть небольшой нюанс, так как кое-какой вполне норамальный
> > Ц++ код не совсем правильно интерпретируется gcc-2.95
> > 
> > даже если не лезть в темплейтные навороты, 
> > хотя plain C уже как-то не совсем ко двору,
> > первое, что приходит в голову
> > 
> > struct A { void f(){}; }; struct B: public A { int i; };
> > 
> > sizeof(B) ?
> > 
> > (большинство компилеров под ia32 считают, что должно получаться 4, а не 8 )
> 
>  В стандарте про гаранитии размеров нет ни слова (кроме того что размер
> потомка будет не меньше размера предка).
Наконец-то докопался до стандарта и нашёл там следующее:

п. 9.3:

A class with an empty sequence of members and base class objects is an
empty class.  Complete objects and member subobjects of an empty class
type  shall have nonzero size.1) 

и далее:

_________________________
1) That is, a base class subobject of an empty class
type may have zero size.

(На самом деле это не стандарт, а draft от Decembeer 1997, последний,
насколько мне известно. Номер пункта в самом стандарте скорее всего не
совпадает, но то, что там эти слова есть --- точно.)

-- 
Best Regards!           | Когда вам платят за работу, надо по крайней мере
Alexey Voinov           | делать вид, что вы работаете...
                        |                         Б.Виан "Осень в Пекине"
voins@voins.program.ru
voins@online.ru
vns@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[sisyphus] Re: C/C++ compilers (was: По поводу сборки пакетов)

[Mikhail Zabaluev]

Hello Alexey,

On Tue, Dec 18, 2001 at 05:23:59PM +0300, Alexey Voinov wrote:
>
> Vlad Harchev wrote
> > > > Надо основываться на стандарте языка, а не на компиляторе. Хорошо 
> > > > написанный код соберется всюду.
> > > 
> > > тут есть небольшой нюанс, так как кое-какой вполне норамальный
> > > Ц++ код не совсем правильно интерпретируется gcc-2.95
> > > 
> > > даже если не лезть в темплейтные навороты, 
> > > хотя plain C уже как-то не совсем ко двору,
> > > первое, что приходит в голову
> > > 
> > > struct A { void f(){}; }; struct B: public A { int i; };
> > > 
> > > sizeof(B) ?
> > > 
> > > (большинство компилеров под ia32 считают, что должно получаться 4, а не 8 )
> > 
> >  В стандарте про гаранитии размеров нет ни слова (кроме того что размер
> > потомка будет не меньше размера предка).
> Наконец-то докопался до стандарта и нашёл там следующее:
> 
> п. 9.3:
> 
> A class with an empty sequence of members and base class objects is an
> empty class.  Complete objects and member subobjects of an empty class
> type  shall have nonzero size.1) 
> 
> и далее:
> 
> _________________________
> 1) That is, a base class subobject of an empty class
> type may have zero size.
> 
> (На самом деле это не стандарт, а draft от Decembeer 1997, последний,
> насколько мне известно. Номер пункта в самом стандарте скорее всего не
> совпадает, но то, что там эти слова есть --- точно.)

Из этого не следует, что sizeof(B) в вышеприведенном примере должен
принимать какое-то строго определенное значение.

P.S. Всегда используйте sizeof -- и ваши волосы не покинут вашу голову
преждевременно :)

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
"The Mets were great in 'sixty eight,
 The Cards were fine in 'sixty nine,
 But the Cubs will be heavenly in nineteen and seventy."
-- Ernie Banks