Re: cross-compiling Debian packages

[peter.kourzanov]

On Tue, Mar 21, 2006 at 12:24:12AM +0300, Nikita V. Youshchenko wrote:
> > I hope that my patches (#357629,  #357658
> > , #357661
> > ) are proper enough:-)
> 
> This is incomplete: not only libgcc does not provide -dcv1, but libstdc++ 
> and -dev and -dbg.

  And -pic probably as well:-)

> Would you be so kind to post undeted patches to these bugs?

  Posted as a followup to the aforementioned patches.

  Hope that your successor will pick them up...

  Pjotr


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question on hurd-i386 Debian architecture

[peter.kourzanov]

On Mon, Mar 20, 2006 at 05:41:26PM -0300, Daniel Ruoso wrote:
> Em S?b, 2006-03-18 ?s 23:17 +0100, Pjotr Kourzanov escreveu:
> > Yes. However, I think that 'setting up buildd' is the least difficult
> > of those tasks. It is by far more difficult to produce patches for all
> > 'standard debian packages' that make them first of all, cross-compile
> > correctly, and (only) then make them uClibc-friendly.
> 
> Sorry, I don't get it. Debian has support for several architectures, why

  Supported architectures, yes. But what about un-supported ones, such
  as i386-uclibc?

> a sub-arch would be harder? Many packages will just work. Remember that
> in such sub-arch, we can have uclibc-dev replacing libc6-dev, solving
> the builddeps...

  Yeah, hopefully this will just work. From my experience, however,
  some minimal but still significant amount of patching will be
  needed.

> 
> Have you ever seen uwoody[1]? there are not so many patches as you're
> claiming to be necessary... I'm really lost about what are you talking
> about...
> 
> [1] http://people.debian.org/~andersee/uwoody/
> 

  I've heard that uwoody is abandoned by its originator... which is
  the reason I stopped looking at that. Is there BTW any comparable
  effort for sarge/etch?

> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cross-compiling Debian packages

[peter.kourzanov]

I think I know now what the problem is, see below...

On Thu, Mar 16, 2006 at 07:35:41PM +0300, Nikita V. Youshchenko wrote:
> >
> > As you see, I get depends with -dcv1 suffix as well as -cross suffix.
> 
> Yes, it's exactly what it should do.
> Each package xxx-arm-cross package created with dpkg-cross >= 1.26 will 
> Provide: xxx-arm-dcv1. In your case, this will not allow libc6-arm-cross 
> created by older dpkg-cross to satisfy dependency - while libc6-arm-cross 
> created by dpkg-cross >= 1.26 will satisfy it.
> 
> And that's correct, because previously dpkg-cross installed files 
> info /usr/arm-linux/, and now it will install files to /usr/arm-linux-gnu/ 
> - so libc6-arm-cross created by older dpkg-cross can't satisfy the 
> dependency.

  Yes, I could guess all of this. However, why do I get -dcv1 as well
as -cross?. Aren't they exclusive? Also, a quick grep in my old
sources for dpkg-cross-1.25 reveals that already that version had -gnu
stuff in...

  When I try to install generated -cross package I get unresolved
dependencies for libgcc1-arm-dcv1. This package is really called
libgcc1-arm-cross and is originated in the gcc source package, and
thus is not coming from dpkg-cross.

  Did you already contribute a patch for gcc/build/control that fixes 
this?

> 
> >   The need for versioning does not justify IMHO the uglyness of
> > -dcv1 when compared to -cross. And it just "feels" wrong, since it is
> > not the type or instances of the files in the package that changed,
> > but the "packaging" of these files... Why couldn't you solve that
> > with version strings?
> 
> I don't see how version string can be safely used here - because version 
> strings from original debs are already used to handle dependences. There 
> are two different dependency requirements - one that original packages 
> should have version not less than ..., and other - that dpkg-cross should 
> be fresh enough to place files inside new tree. I don't see way to use 
> single version strings to handle both things.

  Maybe embed a -dcvX in the version string?

> 
> > > > Also, would you welcome patches that add the ability to handle
> > > > packages built with alternative libc
> > > > implementations, namely uClibc, Dietlibc and Newlib?
> > >
> > > Your patches are welcome.
> > >
> > > I thought that best way to handle other libc's is introducing other
> > > 'architectures', like i386-uclibc. Then tools could just cross-compile
> > > for this 'architecture'.
> >
> > Yes, that's what I did. Please look into 'patches' at
> > http://www.xs4all.nl/~kurzanov/debian/. I had to patch dpkg, as well
> > as dpkg-cross to make it all work.
> 
> Thanks, I'll look at that.
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question on hurd-i386 Debian architecture

[peter.kourzanov]

On Mon, Mar 13, 2006 at 01:46:59PM -0300, Daniel Ruoso wrote:
> Em Seg, 2006-03-13 ?s 17:30 +0100, Pjotr Kourzanov escreveu:
> > Daniel Ruoso wrote:
> > >This is a call for help :). If you want to help, just take over the task
> > >of setting a uclibc-i386 buildd up.
> > What is the need for buildd?
> 
> Basically, what is described in
> http://www.debian.org/devel/buildd/setting-up
> 
> The only difference is that you'll need to cross-compile all the
> packages used by debootstrap when setting up the chroot. After that,
> it's just a matter of time (a long time, I would say).

  Read it. OK, I think it is worth a try on a rainy weekend. I would
really like, however, to focus on standard Debian packages, and not 
start/participate in a totally different effort in parallel with
Debian.

> 
> daniel
> 
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: question on hurd-i386 Debian architecture

[peter.kourzanov]

On Mon, Mar 13, 2006 at 03:39:41PM +0200, Riku Voipio wrote:
> > >[2] http://www.emdebian.org/slind.html
>  
> > This one looks dead.
> 
> I understand we live in a gentoo-driven 0-day bleeding edge culture, but
> this is quite spectacular deducment. SLIND was published exactly two
> weeks ago in FOSDEM and it is already dead? 

  The website was unavailable. It's Ok now. I see though that they
patched gcc and glibc also. In my case, I needed to patch only dpkg,
dpkg-cross and uclibc. These patches I hope will be taken by dpkg,
dpkg-cross and uclibc maintainers...

> 
> >> ...and i386-uclibc[3] alioth project, which is quite staganant ATM 
> >> and hasn't selected arch name yet.
> 
> > >[3] http://alioth.debian.org/projects/i386-uclibc/
> 
> > There were no updates to this one since october. Is it still alive?
> 
> I already said it was stagnant, please pay attention. I brought it into
> attention since it makes more sense to revive a old project than to
> start a completly new one.
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cross-compiling Debian packages

[peter.kourzanov]

On Sat, Mar 11, 2006 at 10:56:35PM +0300, Nikita V. Youshchenko wrote:
> > >
> > >You may look at dpkg-cross ...
> >
> > I did, and I'm using it, thanks:-)
> >
> > What is the deal BTW with that new rewrite_dependencies (as of 1.26)
> > producing bogus names with
> > -dcv1 suffix? I had to comment 2 lines out of dpkg-cross script to make
> > it work for libgpm for instance...
> 
> It's versioning logic. Older dpkg-cross used to have other default paths, 
> so something should be done to avoid packages created by older dpkg-cross 
> to satisfy dependences of packages created by newer dpkg-cross.
> 
> Do you mean it works incorrectly in some cases? If so, I'm interested in 
> details ...

  Well, I have not had the time to track this deeper, but this is the
behaviour I've observed:

Given a package (e.g., gpm slightly modified mice.c) with this info:
---
$ dpkg -I binary-arm/libgpmg1_1.19.6-22.my_arm.deb
 new debian package, version 2.0.
 size 51360 bytes: control archive= 837 bytes.
 500 bytes,15 lines  control  
 273 bytes, 4 lines  md5sums  
 135 bytes, 7 lines   *  postinst #!/bin/sh
 132 bytes, 7 lines   *  postrm   #!/bin/sh
  32 bytes, 1 lines  shlibs   
 Package: libgpmg1
 Version: 1.19.6-22.my
 Section: libs
 Priority: standard
 Architecture: arm
 Depends: libc6 (>= 2.3.5-1), libgcc1 (>= 1:4.0.2)
 Suggests: gpm
 Conflicts: libgpm1 (<< 1.12-3)
 Installed-Size: 108
 Maintainer: Debian GPM Team <[EMAIL PROTECTED]>
 Source: gpm
 Description: General Purpose Mouse - shared library
  This package provides a library that handles mouse requests
  and delivers them to applications. See the description for the 'gpm'
  package for more information.
---

and this dpkg-cross 1.26:
---
$ dpkg-cross -aarm -b binary-arm/libgpmg1_1.19.6-22.my_arm.deb
$ dpkg -I libgpmg1-arm-cross_1.19.6-22.my_all.deb 
 new debian package, version 2.0.
 size 11594 bytes: control archive= 674 bytes.
 654 bytes,16 lines  control  
 147 bytes, 2 lines  md5sums  
  32 bytes, 1 lines  shlibs   
 Package: libgpmg1-arm-cross
 Version: 1.19.6-22.my
 Section: devel
 Priority: extra
 Architecture: all
 Maintainer: Debian GPM Team <[EMAIL PROTECTED]>
 Source: gpm
 Depends: libc6-arm-cross (>= 2.3.5-1), libc6-arm-dcv1, libgcc1-arm-cross (>= 
1:4.0.2), libgcc1-arm-dcv1
 Conflicts: libgpm1-arm-cross (<< 1.12-3)
 Provides: libgpmg1-arm-dcv1
 Description: General Purpose Mouse - shared library (for cross-compiling)
  This package was generated by dpkg-cross for cross compiling.
  .
  This package provides a library that handles mouse requests
  and delivers them to applications. See the description for the 'gpm'
  package for more information.


As you see, I get depends with -dcv1 suffix as well as -cross suffix.
I suspect the following line in dpkg-cross:

my $tmp = $alt; $tmp =~ s/^([^ (]+)/$1-$arch-cross/; push @l, $tmp;

  The need for versioning does not justify IMHO the uglyness of
-dcv1 when compared to -cross. And it just "feels" wrong, since it is
not the type or instances of the files in the package that changed,
but the "packaging" of these files... Why couldn't you solve that
with version strings?


> 
> > Also, would you welcome patches that add the ability to handle packages
> > built with alternative libc
> > implementations, namely uClibc, Dietlibc and Newlib?
> 
> Your patches are welcome.
> 
> I thought that best way to handle other libc's is introducing other 
> 'architectures', like i386-uclibc. Then tools could just cross-compile for 
> this 'architecture'.

Yes, that's what I did. Please look into 'patches' at
http://www.xs4all.nl/~kurzanov/debian/. I had to patch dpkg, as well
as dpkg-cross to make it all work.

> 
> Nikita

Пётр Курзанов.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mipsel binutils/gcc/glibc shared library breakage

[peter.kourzanov]

Thiemo,

  The code builds OK. It even runs if I put less than 4 symbols
in a shared library (it works with 3 symbols for sure). I presume
multigot problem is unrelated to this...

Pjotr Kourzanov

On Thu, Mar 10, 2005 at 12:32:38AM +0100, Thiemo Seufer wrote:
> Pjotr Kourzanov wrote:
> > Dear Debian developers,
> > 
> >   I gather there are some people out there with MIPS little-endian 
> > machines (from mipsel drop discussion) and Debian on it. Do huge shared 
> > libraries (containing >4 symbols) work for you? I am currently 
> > investigating an issue I have with my MIPS32r4, binutils > 2.14.90, 
> > gcc-3.3.5 and glibc 2.3.2 (all Debian sources), which prevents e.g. 
> > Qt/Embedded to be used as shared library.
> 
> The Debian binutils refuse to build multigot libraries with more than
> 16k external symbols. This is a workaround to prevent silent breakage,
> and most larger shared libraries can still be built by compiling with
> -Wa,-xgot.
> 
> 
> Thiemo
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]