Re: Репозиторий

[Victor Wagner <vitus@wagner.pp.ru>]

On Fri, 14 Aug 2015 14:14:46 +0300
Dmitry Belyavsky <beldmit@gmail.com> wrote:

> Привет!
> 
> 
> 2015-08-14 12:03 GMT+03:00 Victor Wagner <vitus@wagner.pp.ru>:
> 
> > On Fri, 14 Aug 2015 10:57:07 +0300
> > Dmitry Belyavsky <beldmit@gmail.com> wrote:
> >
> > > Привет!
> > >
> > > 2015-08-14 10:48 GMT+03:00 Victor Wagner <vitus@wagner.pp.ru>:
> > >
> > > > On Fri, 14 Aug 2015 08:49:54 +0300
> > > > Dmitry Belyavsky <beldmit@gmail.com> wrote:
> > > >
> > > >
> > > > >
> > > > > Ну ок. Для начала можно явно делать так, как ты говоришь.
> > > > >
> > > >
> > > > Попробовал. Оказывается не так всё там просто.
> > > >
> > > > Там в toplevel MAkefile Configure пишет уйму полезных
> > > > переменных, которые бы надо как-то себе втянуть (см переменную
> > > > BUILDENV в этом самом toplevel Makefile). А include в makefile
> > > > непереносимый между разными make.
> > > >
> > > > Кроме того, для того чтобы оно хоть как-то собиралось
> > > > потребовалось во всех строчках сгенерированных make depend
> > > > поменять ../.. на $(TOP). Там полно зависимостей от
> > > > заголовочных файлов самой OpenSSL.
> > > >
> > > > В общем еще надо думать как это собирать. Очевидно одно - если
> > > > мы как-то переменные, описанные в BUILDENV к себе не втащим,
> > > > соберется типичное не то. Хотя бы CROSS_COMPILE и CFLAG
> > > >
> > >
> > > А opensc свой engine как собирает, интересно?
> >
> > У opensc там честный автоконфовский configure. Что, кстати, тоже
> > вариант для создания отдельной build system. Но opensc куда в
> > меньшей степени завязана на кишки openssl, чем мы.
> >
> > Написать автоконфовский configure.in так, чтобы он еще бы нормально
> > поддерживал кросс-компиляцию - это еще тот квест. Большая часть
> > существующих в мире автоконфовских конфигуре написана криво и
> > неправильно, и при попытке кросс-компиляции ломается.
> >
> > Еще можно попытаться воспользоваться pkgconfig-ом. Благо Openssl
> > pkgconfig-овские описания генерирует. Но как с этим работать в
> > случае кросс-компиляции тоже глубоко не понятно
> > --cross-compile-prefix туда не кладется.
> >
> >
> > > Кстати, я уже не помню, как правильно обеспечить независимость от
> > > NID-ов в родной поставке openssl.
> >
> > Насколько я помню, мы писали во все инициализированные структуры
> > NID_undef, потом делали OBJ_create со статическими строками и
> > полученный нид прописывали куда надо уже в рантайме.
> >
> > На мой взгляд, более правильным будет следующее:
> >
> > 1. Позвать OBJ_txt2nid на dotted-decimal представление OID, если оно
> > есть, и на short name, если это, скажем nid некоего режима
> > шифрования. не имеющего своего OID.
> >
> > 2. Если вернуло не NID_undef, использовать (прописать в
> > инициализированные структуры) именно его.
> >
> > 3. Если вернуло NID_undef, звать OBJ_create, но передавать туда
> > динамически размещенные копии всех строк.
> >
> > 4. При выгрузке engine OBJ_cleanup не делать.
> >
> > Тогда получается, что при первой загрузке engine мы загрузим в
> > object database все нужные нам OID-ы которых там изначально не
> > было, и там они и останутся до конца жизни процесса. Если engine
> > выгрузят и загрузят повторно, она найдет те же NID-ы, которые были
> > созданы первой копией.
> >
> > Если же часть (произвольная) OID-ов в Object Database была, то мы
> > будем использовать те NID-ы, которые были.
> >
> 
> Под юниксы это пройдёт, хотя, возможно, получим ругань на утечку
> памяти. Под Windows - я не уверен.