[devel] Re: sqlite3 -- fixed x86_64 build

[devel] Re: sqlite3 -- fixed x86_64 build

[Alexey Tourbin]

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

On Tue, Sep 07, 2004 at 12:25:53AM +0400, Денис Смирнов wrote:
>>> --- RPM/SPECS/sqlite3.spec     2004-08-13 00:38:25 +0000
>>> +++ tmp/sqlite3.spec.new       2004-09-06 15:44:04 +0000
>>> @@ -61,13 +61,22 @@ embeddable, zero-configuration SQL datab
>>>  %configure --enable-utf8
>>>  %make_build all libtcl%name.la
>>> 
>>> -%__subst 's#usr/lib/sqlite#usr/lib/tcl#g' libtcl%name.la
>>> +%__subst 's#/usr/lib/sqlite#%_libdir/tcl#g' libtcl%name.la
>>>  %make_build tcl%name doc
>>> 
>>>  %install
>>>  %makeinstall
>>> +
>>> +if [ "/usr/lib" != "%_libdir" ]; then
>>> +    mv -f %buildroot/usr/lib %buildroot/%_libdir
>>> +fi
>>> +
>>>  %__install -pD -m644 sqlite.1 %buildroot%_man1dir/%name.1
>>> 
>>> +subst "s#'/usr/lib'#'%_libdir'#g" *.la
>>> +subst "s#/usr/lib/#%_libdir/#g" *.la
>>> +
>>> +
>>>  %__mkdir_p %buildroot%_tcllibdir
>>>  libtool --mode=install %__install libtcl%name.la %buildroot%_tcllibdir
>>>  %__rm -fv %buildroot%_tcllibdir/*.{a,la}

>  AT> Hi, а зачем это делать?
>  AT> Ведь %_libdir подставляется в %configure и должен влиять на всё остальное:
>  AT> $ rpm --eval %configure | grep libdir
>  AT>         --libdir=/usr/lib \
>  AT> $
>  AT> По идее просто так должно работать...
> 
> Судя по всему, из-за того что авторы sqlite ламеры и не везде используют
> этот libdir. У меня без того патчика не собралось :-(

--- Makefile.in~	2004-07-19 23:16:19 +0000
+++ Makefile.in	2004-09-07 05:26:37 +0000
@@ -32,6 +32,7 @@
 #
 prefix = @prefix@
 exec_prefix = @exec_prefix@
+libdir = @libdir@
 INSTALL = @INSTALL@
 LIBTOOL = ./libtool
 RELEASE = @ALLOWRELEASE@
@@ -545,14 +546,14 @@
 	mv $(DOC) doc
 
 install:	sqlite3 libsqlite3.la sqlite3.h
-	$(INSTALL) -d $(DESTDIR)$(exec_prefix)/lib
-	$(LTINSTALL) libsqlite3.la $(DESTDIR)$(exec_prefix)/lib
+	$(INSTALL) -d $(DESTDIR)$(libdir)
+	$(LTINSTALL) libsqlite3.la $(DESTDIR)$(libdir)
 	$(INSTALL) -d $(DESTDIR)$(exec_prefix)/bin
 	$(LTINSTALL) sqlite3 $(DESTDIR)$(exec_prefix)/bin
 	$(INSTALL) -d $(DESTDIR)$(prefix)/include
 	$(INSTALL) -m 0644 sqlite3.h $(DESTDIR)$(prefix)/include
-	$(INSTALL) -d $(DESTDIR)$(exec_prefix)/lib/pkgconfig; 
-	$(INSTALL) -m 0644 sqlite3.pc $(DESTDIR)$(exec_prefix)/lib/pkgconfig; 
+	$(INSTALL) -d $(DESTDIR)$(libdir)/pkgconfig; 
+	$(INSTALL) -m 0644 sqlite3.pc $(DESTDIR)$(libdir)/pkgconfig; 
 
 clean:	
 	rm -f *.lo *.la *.o sqlite3@TARGET_EXEEXT@ libsqlite3.la

С этим патчем собирается до следующего места:

$ rpm --define '_libdir /usr/lib64' -bb ~/RPM/SPECS/sqlite3.spec
...
+ /bin/mkdir -p /home/at/tmp/sqlite3-buildroot/usr/lib64/tcl
+ libtool --mode=install /bin/install libtclsqlite3.la /home/at/tmp/sqlite3-buildroot/usr/lib64/tcl
libtool-default: install: error: cannot install `libtclsqlite3.la' to a directory not ending in /usr/lib/tcl
$

По-видимому, в этом есть смысл.  Т.е. нужно сначала пересобрать tcl под
lib64, а потом уже расширения к tcl собирать.  Просто так перекладывать
из lib в lib64 -- плохо.

Думаю, что работу по портированию на x86_64 нужно уже сделать доступной
(особенно базовую систему для сборки).  Поэтому делаю CC в devel@.

> -- 
> С уважением, Денис
> http://freesource.info

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

Re: [devel] Re: sqlite3 -- fixed x86_64 build

[Anton Farygin]

Alexey Tourbin пишет:
> On Tue, Sep 07, 2004 at 12:25:53AM +0400, Денис Смирнов wrote:
> 
>>>>--- RPM/SPECS/sqlite3.spec     2004-08-13 00:38:25 +0000
>>>>+++ tmp/sqlite3.spec.new       2004-09-06 15:44:04 +0000
>>>>@@ -61,13 +61,22 @@ embeddable, zero-configuration SQL datab
>>>> %configure --enable-utf8
>>>> %make_build all libtcl%name.la
>>>>
>>>>-%__subst 's#usr/lib/sqlite#usr/lib/tcl#g' libtcl%name.la
>>>>+%__subst 's#/usr/lib/sqlite#%_libdir/tcl#g' libtcl%name.la
>>>> %make_build tcl%name doc
>>>>
>>>> %install
>>>> %makeinstall
>>>>+
>>>>+if [ "/usr/lib" != "%_libdir" ]; then
>>>>+    mv -f %buildroot/usr/lib %buildroot/%_libdir
>>>>+fi
>>>>+
>>>> %__install -pD -m644 sqlite.1 %buildroot%_man1dir/%name.1
>>>>
>>>>+subst "s#'/usr/lib'#'%_libdir'#g" *.la
>>>>+subst "s#/usr/lib/#%_libdir/#g" *.la
>>>>+
>>>>+
>>>> %__mkdir_p %buildroot%_tcllibdir
>>>> libtool --mode=install %__install libtcl%name.la %buildroot%_tcllibdir
>>>> %__rm -fv %buildroot%_tcllibdir/*.{a,la}
> 
> 
>> AT> Hi, а зачем это делать?
>> AT> Ведь %_libdir подставляется в %configure и должен влиять на всё остальное:
>> AT> $ rpm --eval %configure | grep libdir
>> AT>         --libdir=/usr/lib \
>> AT> $
>> AT> По идее просто так должно работать...
>>
>>Судя по всему, из-за того что авторы sqlite ламеры и не везде используют
>>этот libdir. У меня без того патчика не собралось :-(
> 
> 
> --- Makefile.in~	2004-07-19 23:16:19 +0000
> +++ Makefile.in	2004-09-07 05:26:37 +0000
> @@ -32,6 +32,7 @@
>  #
>  prefix = @prefix@
>  exec_prefix = @exec_prefix@
> +libdir = @libdir@
>  INSTALL = @INSTALL@
>  LIBTOOL = ./libtool
>  RELEASE = @ALLOWRELEASE@
> @@ -545,14 +546,14 @@
>  	mv $(DOC) doc
>  
>  install:	sqlite3 libsqlite3.la sqlite3.h
> -	$(INSTALL) -d $(DESTDIR)$(exec_prefix)/lib
> -	$(LTINSTALL) libsqlite3.la $(DESTDIR)$(exec_prefix)/lib
> +	$(INSTALL) -d $(DESTDIR)$(libdir)
> +	$(LTINSTALL) libsqlite3.la $(DESTDIR)$(libdir)
>  	$(INSTALL) -d $(DESTDIR)$(exec_prefix)/bin
>  	$(LTINSTALL) sqlite3 $(DESTDIR)$(exec_prefix)/bin
>  	$(INSTALL) -d $(DESTDIR)$(prefix)/include
>  	$(INSTALL) -m 0644 sqlite3.h $(DESTDIR)$(prefix)/include
> -	$(INSTALL) -d $(DESTDIR)$(exec_prefix)/lib/pkgconfig; 
> -	$(INSTALL) -m 0644 sqlite3.pc $(DESTDIR)$(exec_prefix)/lib/pkgconfig; 
> +	$(INSTALL) -d $(DESTDIR)$(libdir)/pkgconfig; 
> +	$(INSTALL) -m 0644 sqlite3.pc $(DESTDIR)$(libdir)/pkgconfig; 
>  
>  clean:	
>  	rm -f *.lo *.la *.o sqlite3@TARGET_EXEEXT@ libsqlite3.la
> 
> С этим патчем собирается до следующего места:
> 
> $ rpm --define '_libdir /usr/lib64' -bb ~/RPM/SPECS/sqlite3.spec
> ...
> + /bin/mkdir -p /home/at/tmp/sqlite3-buildroot/usr/lib64/tcl
> + libtool --mode=install /bin/install libtclsqlite3.la /home/at/tmp/sqlite3-buildroot/usr/lib64/tcl
> libtool-default: install: error: cannot install `libtclsqlite3.la' to a directory not ending in /usr/lib/tcl
> $
> 
> По-видимому, в этом есть смысл.  Т.е. нужно сначала пересобрать tcl под
> lib64, а потом уже расширения к tcl собирать.  Просто так перекладывать
> из lib в lib64 -- плохо.
> 
> Думаю, что работу по портированию на x86_64 нужно уже сделать доступной
> (особенно базовую систему для сборки).  Поэтому делаю CC в devel@.

Да, согласен. IMHO уже пора выкладывать все что есть - наравне с Sisyphus.

А точнее - надо делать NMU для всех пакетов, которые исправлялись, 
выкладывать из в Sisyphus и проводить ежедневные пересборки Sisyphus под 
x86_64, а все что собралось - выкладывать в отдельный репозитарий.

Rgds,
Rider

[devel] Re: sqlite3 -- fixed x86_64 build

[Michael Shigorin]

On Tue, Sep 07, 2004 at 12:10:33PM +0400, Anton Farygin wrote:
> >Думаю, что работу по портированию на x86_64 нужно уже сделать
> >доступной (особенно базовую систему для сборки).  Поэтому
> >делаю CC в devel@.
> Да, согласен. IMHO уже пора выкладывать все что есть - наравне
> с Sisyphus.

"Наравне" в смысле рядом, а не как архитектуру в рамках Sisyphus?
Или это до сливания доработок в него?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: sqlite3 -- fixed x86_64 build

[Anton Farygin]

Michael Shigorin пишет:
> On Tue, Sep 07, 2004 at 12:10:33PM +0400, Anton Farygin wrote:
> 
>>>Думаю, что работу по портированию на x86_64 нужно уже сделать
>>>доступной (особенно базовую систему для сборки).  Поэтому
>>>делаю CC в devel@.
>>
>>Да, согласен. IMHO уже пора выкладывать все что есть - наравне
>>с Sisyphus.
> 
> 
> "Наравне" в смысле рядом, а не как архитектуру в рамках Sisyphus?
> Или это до сливания доработок в него?

Как архитектуру в рамках Sisyphus.

Rgds,
Rider

[devel] Re: sqlite3 -- fixed x86_64 build

[Денис Смирнов]

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

On Tue, Sep 07, 2004 at 09:54:05AM +0400, Алексей Турбин wrote:

 AT> С этим патчем собирается до следующего места:
 AT> $ rpm --define '_libdir /usr/lib64' -bb ~/RPM/SPECS/sqlite3.spec
 AT> ...
 AT> + /bin/mkdir -p /home/at/tmp/sqlite3-buildroot/usr/lib64/tcl
 AT> + libtool --mode=install /bin/install libtclsqlite3.la /home/at/tmp/sqlite3-buildroot/usr/lib64/tcl
 AT> libtool-default: install: error: cannot install `libtclsqlite3.la' to a directory not ending in /usr/lib/tcl
 AT> $
 AT> По-видимому, в этом есть смысл.  Т.е. нужно сначала пересобрать tcl под
 AT> lib64, а потом уже расширения к tcl собирать.  Просто так перекладывать
 AT> из lib в lib64 -- плохо.

Обижаешь :-( tcl уже пересобран (но несколько неправильно, возможно).

Я не могу понять, откуда внутри .la взялось /usr/lib/tcl (я уже говорил,
что в libtool разбираюсь как свинья в апельсинах). Я пока предыдущую
версию sqlite собирал матерился (там ведь тоже грязный хак с subst у
меня).

-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] Re: sqlite3 -- fixed x86_64 build

[Denis Smirnov]

On Tue, Sep 07, 2004 at 12:10:33PM +0400, Anton Farygin wrote:

 AF> А точнее - надо делать NMU для всех пакетов, которые исправлялись, 
 AF> выкладывать из в Sisyphus и проводить ежедневные пересборки Sisyphus под 
 AF> x86_64, а все что собралось - выкладывать в отдельный репозитарий.

wtf NMU?

Вообще с таким подходом я полностью согласен.

Только во-первых сейчас x86_64 должен быть, видимо, в отдельном
репозитории (и из-за объёмов, товарищи зеркалирующие повесятся, и из-за
стабильности, которая сейчас скорее ближе к Daedalus'у). И, естественно,
если делать какой-то внутренней анонс (в sisyphus@), то и в нём, и в корне
репозитория, должно быть ясное и недвусмысленное упоминание что это
глубокая альфа, и что проблем с security там потенциальных -- как собак
нерезаных, и на что-то кроме девелоперского сервера или рабочей станции
сейчс его будет ставить только камикадзе.

-- 
С уважением, Денис

http://freesource.info

Re: [devel] Re: sqlite3 -- fixed x86_64 build

[Денис Смирнов]

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

On Tue, Sep 07, 2004 at 12:32:33PM +0400, Anton Farygin wrote:

 AF> Как архитектуру в рамках Sisyphus.

Рано. А вот отдельным репозиторием уже нужно.
 
-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] Re: sqlite3 -- fixed x86_64 build

[Anton Kachalov]

On Tue, Sep 07, 2004 at 02:49:32PM +0400, Denis Smirnov wrote:
...
> 
> Только во-первых сейчас x86_64 должен быть, видимо, в отдельном
> репозитории (и из-за объёмов, товарищи зеркалирующие повесятся, и из-за
> стабильности, которая сейчас скорее ближе к Daedalus'у). И, естественно,
> если делать какой-то внутренней анонс (в sisyphus@), то и в нём, и в корне
> репозитория, должно быть ясное и недвусмысленное упоминание что это
> глубокая альфа, и что проблем с security там потенциальных -- как собак
> нерезаных, и на что-то кроме девелоперского сервера или рабочей станции
> сейчс его будет ставить только камикадзе.
К вопросу о репозитарии. Вторым шагом будет сборка некоторых библиотек
(libgcc, libstdc++, glibc, pam, etc...) в среде x86_64, но с флагом "-m32"
для возможности запускать 32-х битные прикладухи. Один из способов решения
именования пакетов - добавлять "-32" в конец имени.Но как лучше сделать?
Ведь некторые либы могу содержать и документацию,которая по файлам будет
пересекаться с не x86_64-сборкой.Баги вешать?Чтоб выносили всё не
arch-зависимое в отдельный пакет ala -common, -doc, etc...Тогда такую
сборку можно будет заряжать автоматом и на лету добавлять -32.
Какие есть предложения?

По части некорректного использования /usr/lib вместо /usr/share будут
пинаться такие пакеты патчами, а так же их мантейнеры :) в случае, когда
такой (/usr/lib --> /usr/share) переезд будет возможен.

Rgds,
Anton

Re: [devel] Re: sqlite3 -- fixed x86_64 build

[Денис Смирнов]

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

On Tue, Sep 07, 2004 at 03:41:30PM +0400, Anton Kachalov wrote:

 AK> К вопросу о репозитарии. Вторым шагом будет сборка некоторых библиотек
 AK> (libgcc, libstdc++, glibc, pam, etc...) в среде x86_64, но с флагом "-m32"
 AK> для возможности запускать 32-х битные прикладухи. Один из способов решения
 AK> именования пакетов - добавлять "-32" в конец имени.Но как лучше сделать?
 AK> Ведь некторые либы могу содержать и документацию,которая по файлам будет
 AK> пересекаться с не x86_64-сборкой.Баги вешать?Чтоб выносили всё не
 AK> arch-зависимое в отдельный пакет ala -common, -doc, etc...Тогда такую
 AK> сборку можно будет заряжать автоматом и на лету добавлять -32.
 AK> Какие есть предложения?

Идеал -- конечно делить пакеты. Только у нас тогда их слишком много
образуется.

Идеал -- 32-х битные сборки должны быть без документации, без того, без
сего. Делаться из тех же srpm и содержать в себе только бинарники. При
этом %name-32 должен требовать %name.

Правда некрасиво это как-то получается.

/me начинает понимать, что кэш apt'а скоро будет занимать больше чем весь
/usr :-)

-- 
С уважением, Денис

http://freesource.info


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