Bug#644990: NEWS.Debian.gz: s/$arch/triplet

2011-10-14 Thread Sedat Dilek 
On Fri, Oct 14, 2011 at 9:44 PM, Jonathan Nieder jrnie...@gmail.com wrote:
 Sedat Dilek wrote:

 I am unsure how to interpret you might try to pass the following
 option to your:  -B/usr/lib/triplet -I/usr/include/triplet?

 Normally, I would expect to do:

 export CFLAGS=$CFLAGS -B/usr/lib/triplet -I/usr/include/triplet

 But in case of gcc-trunk upstream this change impacts:
 [...]

 It means that you might want to pass those flags to the compiler.
 The compiler doesn't examine any environment variables, so your
 export CFLAGS incantation isn't going to do that, depending on the
 build system.


You mean something like make CC='gcc ...' ?
What exactly do I need to pass?

 When building a compiler, there is a bootstrap step, meaning there are
 multiple compilers to pass the flags to.  I thought there was already
 a bug report about making this easier (#637232) which unfortunately no
 one seems to be working on.


Unfortunately.
I just built a MIPSEL toolchain w/o my workarounds, today. Worked nicely.
The problem seems to affect gcc-trunk from upstream.

 The generated compiler needs a wrapper-script to use -B and -I options.
 BTW, I could compile mesa, but not use the same wrapper-script with
 kernel-buildsystem from Debian Kernel Team.

 That's probably because in debian/config.defines, we have

        compiler: 'gcc-4.5'

 So if your gcc-4.5 comes from upstream, you would need to install a
 /usr/local/bin/gcc-4.5 wrapper, too.


With my 2 workarounds I can use my gcc-4.7 binaries OOTB. No
wrapper-script etc. (so I prefer my way).

 But what does this have to do with the triplet text in libc6-dev's
 NEWS.Debian.gz?


I wanted to point out that building with -B and -I options might not
be enough to really use your generated new binaries.

- Sedat -



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuvbtv81hoy-_8f_o1zveyff4daaezw+sdz7wdvut3g...@mail.gmail.com

Bug#644986: i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?

2011-10-11 Thread Sedat Dilek 
Some additional informations on created gcc-4.7 compiler:

# which gcc-4.7
/usr/bin/gcc-4.7

# l /usr/bin/gcc-4.7
lrwxrwxrwx 1 root root 24 Jul 31 14:28 /usr/bin/gcc-4.7 -
/opt/gcc-4.7/bin/gcc-4.7

# gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=gcc-4.7
COLLECT_LTO_WRAPPER=/opt/gcc-4.7/lib/gcc/i486-linux-gnu/4.7.0/lto-wrapper
Target: i486-linux-gnu
Configured with: ../gcc-4.7-20111008/configure --prefix=/opt/gcc-4.7
--libdir=/opt/gcc-4.7/lib --libexecdir=/opt/gcc-4.7/lib
--program-suffix=-4.7 --enable-clocale=gnu --enable-languages=c,c++
--enable-shared --enable-threads=posix --disable-bootstrap
--disable-libssp --disable-multilib --disable-nls --with-system-zlib
--without-cloog --without-ppl --with-arch-32=i586 --with-tune=generic
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.0 20111008 (experimental) (GCC)



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuxwas7jfuy3mqpjjecmuy_expujxljcl4totn4ock3...@mail.gmail.com

Bug#644986: i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?

2011-10-11 Thread Sedat Dilek 
[ RESEND ]

I played again with CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET by exporting them.

-I/usr/include/${HOST_SYSTEM_MULTIARCH_TYPE} ...
...catches the gnu/stub-32.h issue.

-B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE} ...
...does NOT catch the problem with crt*.o files.

-B/lib/${HOST_SYSTEM_MULTIARCH_TYPE}
-B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE} ...
... NOPE, too.

- Sedat -
--- scripts/build_gcc-snapshot_v1.sh	2011-10-11 15:36:19.879266636 +0200
+++ scripts/build_gcc-snapshot_v3.sh	2011-10-11 16:30:00.962772133 +0200
@@ -25,6 +25,8 @@ BUILD_SYSTEM_TYPE=$(dpkg-architecture -q
 HOST_SYSTEM_TYPE=$(dpkg-architecture -qDEB_HOST_GNU_TYPE)
 TARGET_SYSTEM_TYPE=i486-linux-gnu
 
+HOST_SYSTEM_MULTIARCH_TYPE=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
+
 PREFIX=/opt/${PKG_NAME}-${PKG_VER}
 
 LIB_DIR=${PREFIX}/lib
@@ -41,6 +43,9 @@ echo # CC  ... $CC
 echo # CXX ... $CXX
 echo # CPP ... $CPP
 
+export CFLAGS_FOR_TARGET=-g -O2 -B/lib/${HOST_SYSTEM_MULTIARCH_TYPE} -B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE} -I/usr/include/${HOST_SYSTEM_MULTIARCH_TYPE}
+export CXXFLAGS_FOR_TARGET=-g -O2 -B/lib/${HOST_SYSTEM_MULTIARCH_TYPE} -B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE} -I/usr/include/${HOST_SYSTEM_MULTIARCH_TYPE}
+
 ##LD_PRELOAD_FOR_BUILD=${PREFIX}/lib/libgcc_s.so.1
 ##export LD_PRELOAD=${LD_PRELOAD_FOR_BUILD}

Bug#637342: Trivial: File relicts from SVN repository

2011-08-12 Thread Sedat Dilek 
On Wed, Aug 10, 2011 at 7:35 PM, Aurelien Jarno aurel...@aurel32.net wrote:
 tag 637342 + unreproducible
 thanks

 On Wed, Aug 10, 2011 at 04:36:24PM +0200, Sedat Dilek wrote:
 Package: libc-bin
 Version: 2.13-16
 Severity: normal

 Hi,

 on d-u I noticed some SVN file relicts.

 # dpkg -S /etc/ld.so.conf.d/.svn/entries
 /etc/ld.so.conf.d/.svn/text-base/libc.conf.svn-base
 libc-bin: /etc/ld.so.conf.d/.svn/entries
 libc-bin: /etc/ld.so.conf.d/.svn/text-base/libc.conf.svn-base

 # dpkg -L libc-bin | grep -e .svn
 /etc/ld.so.conf.d/.svn/entries
 /etc/ld.so.conf.d/.svn/text-base/libc.conf.svn-base


 Have you build this package yourself? These files are not in the
 packages that is present on the mirror:

 $ wget -q 
 http://ftp.debian.org/debian/pool/main/e/eglibc/libc-bin_2.13-16_i386.deb
 $ dpkg -c libc-bin_2.13-16_i386.deb | grep svn
 $


 --
 Aurelien Jarno                          GPG: 1024D/F1BCDB73
 aurel...@aurel32.net                 http://www.aurel32.net


As said on IRC, it was indeed an issue in my own packages which I
rebuilt with debian-dir from glibc SVN trunk.
Sorry for the noise and letting you wait for my answer.

- Sedat -



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczux-lsq7ztrd9xcnwzragiqsjlymxu9tuopbtt_hoer...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-10 Thread Sedat Dilek 
On Wed, Aug 10, 2011 at 5:15 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Hi,

 Sedat Dilek wrote:

 Do I need additional patches to gcc trunk (I am using the weekly
 gcc-4.7 snapshot tarballs)?

 No need for patches.  My build of gcc trunk finally finished:

        $ ./configure --prefix=$HOME/opt/gcc \
                CFLAGS_FOR_TARGET=-g -O2 -B/usr/lib/x86_64-linux-gnu \
                CXXFLAGS_FOR_TARGET=-g -O2 -B/usr/lib/x86_64-linux-gnu
        $ make FLAGS_FOR_TARGET='-B$(build_tooldir)/bin/ '\
 '-B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include '\
 '-isystem $(build_tooldir)/sys-include '\
 '-B/usr/lib/x86_64-linux-gnu' \
                BOOT_CFLAGS=-g -O2 -B/usr/lib/x86_64-linux-gnu
        $ make FLAGS_FOR_TARGET='-B$(build_tooldir)/bin/ '\
 '-B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include '\
 '-isystem $(build_tooldir)/sys-include '\
 '-B/usr/lib/x86_64-linux-gnu' \
                BOOT_CFLAGS=-g -O2 -B/usr/lib/x86_64-linux-gnu \
                install

 The resulting compiler even seems to work, as long as you pass
 -B/usr/lib/x86_64-linux-gnu to it.

 Yes, it ought to be easier.  Maybe FLAGS_FOR_TARGET does everything we
 need.  I'd be happy to review a patch that teaches configure.ac to
 handle something like

        $ ./configure --prefix=$HOME/opt/gcc \
                --extra-flags-for-target=-B/usr/lib/x86_64-linux-gnu \
                BOOT_FLAGS='-g -O2 -B/usr/lib/x86_64-linux-gnu'
        $ make
        $ make install

 [...]
 I heard of a gcc multiarch patchset sent to upstream from debian-gcc
 team - you have an URL?

 I'd be interested in the answer to this if there is one, too.

 Thanks, Sedat.
 Jonathan


First of all, thanks for jumping into the issue and sharing your
thoughts and results/testing.

For i386 I needed to expicitly set -I option with -B option (see [1]),
otherwise I had several breakages with gnu/stubs-32.h when playing
with *_FOR_TARGET options.


### List of *_FOR_TARGET options:

1. CFLAGS_FOR_TARGET
2. CXXFLAGS_FOR_TARGET
3. LDFLAGS_FOR_TARGET
4. FLAGS_FOR_TARGET

### Like you I have explicitly set, but with -I option (always
combined with below options):

$ export CFLAGS_FOR_TARGET='-g -O2 -B/usr/lib/i386-linux-gnu
-I/usr/include/i386-linux-gnu'
$ export CXXFLAGS_FOR_TARGET='-g -O2 -B/usr/lib/i386-linux-gnu
-I/usr/include/i386-linux-gnu'

### Playing with LDFLAGS_FOR_TARGET:

1st-Try:
export LDFLAGS_FOR_TARGET=-L/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}
-Wl,-rpath-link=/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}:/lib/${HOST_SYSTEM_MULTIARCH_TYPE}:/usr/lib

2nd-Try:
export LDFLAGS_FOR_TARGET=-B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}
-I/usr/include/${HOST_SYSTEM_MULTIARCH_TYPE}

3rd-Try:
export LDFLAGS_FOR_TARGET=-L/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}
-Wl,-rpath-link=/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}

NOPE: All try-outs are passed-by but did not work as expected, I got
crt*.o was not found. But, isn't LDFLAGS searching for so-libs?

### Playing with FLAGS_FOR_TARGET:

$ make FLAGS_FOR_TARGET=${FLAGS_FOR_TARGET}
-B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}
-I/usr/include/${HOST_SYSTEM_MULTIARCH_TYPE}

OK: This leads to a successful build, did not test the compiler yet
(flags by-passed to xgcc).

ANYWAY, these workarounds should not be necessary, it should work OOTB.
Not sure, what's wrong.
What do the experts say?

- Sedat -

[1] http://anonscm.debian.org/viewvc/pkg-glibc?view=revisionrevision=4863



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuw__9slouodhmjnwlfa+lopcrsex6dwmjgmqag1wt1...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-10 Thread Sedat Dilek 
On Wed, Aug 10, 2011 at 3:09 PM, Sedat Dilek sedat.di...@googlemail.com wrote:
 On Wed, Aug 10, 2011 at 5:15 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Hi,

 Sedat Dilek wrote:
[...]
 ### Playing with FLAGS_FOR_TARGET:

 $ make FLAGS_FOR_TARGET=${FLAGS_FOR_TARGET}
 -B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}
 -I/usr/include/${HOST_SYSTEM_MULTIARCH_TYPE}

 OK: This leads to a successful build, did not test the compiler yet
 (flags by-passed to xgcc).


When building mesa wizh new gcc-4.7:

configure:3094: error: C compiler cannot create executables

15 compiler builds for nothing, grr.

- Sedat -



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuwmtt7-9wfn55zbw3qjijaw_pn9qn8pyypdpkmvgvv...@mail.gmail.com

Bug#637342: Trivial: File relicts from SVN repository

2011-08-10 Thread Sedat Dilek 
Package: libc-bin
Version: 2.13-16
Severity: normal

Hi,

on d-u I noticed some SVN file relicts.

# dpkg -S /etc/ld.so.conf.d/.svn/entries
/etc/ld.so.conf.d/.svn/text-base/libc.conf.svn-base
libc-bin: /etc/ld.so.conf.d/.svn/entries
libc-bin: /etc/ld.so.conf.d/.svn/text-base/libc.conf.svn-base

# dpkg -L libc-bin | grep -e .svn
/etc/ld.so.conf.d/.svn/entries
/etc/ld.so.conf.d/.svn/text-base/libc.conf.svn-base

- Sedat -

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.0.1-1-rt-686-pae (SMP w/1 CPU core; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuuhpqbsy8wo9pff61a8h1225v5rvfc55jrx4cdarsb...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-10 Thread Sedat Dilek 
On Wed, Aug 10, 2011 at 4:47 PM, Jonathan Nieder jrnie...@gmail.com wrote:
 Sedat Dilek wrote:

 When building mesa wizh new gcc-4.7:

 configure:3094: error: C compiler cannot create executables

 But of course.  You'll need to pass 'CC=gcc -B/usr/lib/...
 -I/usr/include/...' to mesa's configure script.

 You can experience the same thing by building a hello world program,
 too.


NAH... the gcc with my symlinks workaround for gnu/stubs-32.h and
crt*.o works w/o such hackz.
This is a step back :-(.

- Sedat -



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuu5isueo+evcyfnxwooxfpulucwwgrehrpa6b8vumw...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-09 Thread Sedat Dilek 
Package: libc6-dev-amd64
Version: 2.13-16
Severity: normal

Hi,

I thought this stuff is fixed?
When building gcc-4.7 snapshot, I get again this gnu/stubs-32.h error.

My build breaks like this:
...
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such
file or directory
compilation terminated.

Investigating:

$ LC_ALL=C ls -l /usr/include/gnu/
total 20
-rw-r--r-- 1 root root 2943 Aug  9 15:41 lib-names.h
-rw-r--r-- 1 root root 1337 Aug  9 15:41 libc-version.h
-rw-r--r-- 1 root root 1813 Aug  9 15:45 option-groups.h
-rw-r--r-- 1 root root  604 Aug  9 15:45 stubs-64.h
-rw-r--r-- 1 root root  315 Aug  9 15:41 stubs.h

$ dpkg -S /usr/include/gnu/stubs.h
libc6-dev-amd64: /usr/include/gnu/stubs.h

( Not sure if this a good idea that /usr/include/{bits,gnu,sys}/*.h
belongs to libc6-dev-amd64 package. )

In previous eglibc packages {bits,gnu,sys} dirs were symlinked to
i386-linux-gnu/{bits,gnu,sys}, now:

$ l /usr/include/i386-linux-gnu/
insgesamt 72
drwxr-xr-x   5 root root  4096  9. Aug 15:51 .
drwxr-xr-x 116 root root 20480  9. Aug 15:51 ..
drwxr-xr-x   2 root root 12288  9. Aug 15:51 bits
-rw-r--r--   1 root root 10883 11. Jun 21:58 ffi.h
-rw-r--r--   1 root root  3496 11. Jun 21:58 ffitarget.h
-rw-r--r--   1 root root  3291  9. Aug 15:17 fpu_control.h
drwxr-xr-x   2 root root  4096  9. Aug 15:51 gnu
drwxr-xr-x   2 root root 12288  9. Aug 15:51 sys

$ l /usr/include/i386-linux-gnu/gnu/stubs*
-rw-r--r-- 1 root root 624  9. Aug 15:20
/usr/include/i386-linux-gnu/gnu/stubs-32.h
-rw-r--r-- 1 root root 315  9. Aug 15:17 /usr/include/i386-linux-gnu/gnu/stubs.h

XXX: Workaround

# cd /usr/include/gnu
# ln -sf ../i386-linux-gnu/gnu/stubs-32.h ./
# LC_ALL=C l stubs*.h
lrwxrwxrwx 1 root root  32 Aug  9 17:16 stubs-32.h -
../i386-linux-gnu/gnu/stubs-32.h
-rw-r--r-- 1 root root 604 Aug  9 15:45 stubs-64.h
-rw-r--r-- 1 root root 315 Aug  9 15:41 stubs.h

This lets the build continue, until crt*.o breakage...

Regards,
- Sedat -

P.S.: I have rebuilt -16 with gcc-4.6 and tested against -16 from official repo.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.0.1-1-rt-686-pae (SMP w/1 CPU core; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-dev-amd64 depends on:
ii  libc6-amd64 2.13-16 Embedded GNU C Library: 64bit Shar
ii  libc6-dev   2.13-16 Embedded GNU C Library: Developmen

Versions of packages libc6-dev-amd64 recommends:
ii  gcc-multilib  4:4.6.1-2  GNU C compiler (multilib files)

libc6-dev-amd64 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+icZUUOCOiU18sSBbJyKYY2Swan1ir0UR-36x-Na_TybX=e...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-09 Thread Sedat Dilek 
On Tue, Aug 9, 2011 at 6:23 PM, Jonathan Nieder jrnie...@gmail.com wrote:
 retitle 637218 [i386] cannot use gnu/stubs.h with multiarch-unaware toolchain 
 (fatal error: gnu/stubs-32.h: No such file or directory)
 quit

 Jonathan Nieder wrote:

 retitle 637218 libc6-dev: moving headers to /usr/include/triplet breaks 
 external multiarch unaware applications
 [...]
 This lets the build continue, until crt*.o breakage...

 They are one and the same problem.

 On second thought, I think I missed the point.  I would have thought
 that /usr/include/gnu would be a symlink to
 /usr/include/i386-linux-gnu/gnu on i386.  What does

        ls -ld /usr/include/gnu

 say?


It's now a directory containing header-files from libc6-dev-amd64
package (see -16 changelog).

root@tbox:~# ls -ld /usr/include/gnu
drwxr-xr-x 2 root root 4096  9. Aug 18:20 /usr/include/gnu

( I can live with my gnu/stubs-32.h workaround ).

Trying your workaround from [1], building (removed all my workarounds)...


- Sedat -

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=80;bug=629819



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+icZUXghHNv=8V0Wj5q=-sn_3vcgdb-thsmjrmlyn_x_vz...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-09 Thread Sedat Dilek 
On Tue, Aug 9, 2011 at 7:23 PM, Aurelien Jarno aurel...@aurel32.net wrote:
 merge 629819 637218
 thanks

 On Tue, Aug 09, 2011 at 05:30:33PM +0200, Sedat Dilek wrote:
 Package: libc6-dev-amd64
 Version: 2.13-16
 Severity: normal

 Hi,

 I thought this stuff is fixed?
 When building gcc-4.7 snapshot, I get again this gnu/stubs-32.h error.

 My build breaks like this:
 ...
 /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such
 file or directory
 compilation terminated.

[...]
 $ l /usr/include/i386-linux-gnu/gnu/stubs*
 -rw-r--r-- 1 root root 624  9. Aug 15:20
 /usr/include/i386-linux-gnu/gnu/stubs-32.h
 -rw-r--r-- 1 root root 315  9. Aug 15:17 
 /usr/include/i386-linux-gnu/gnu/stubs.h

 stubs-32.h is only there because it's an i386 only header. The problem
 is that your compiler  is not multiarch aware. Everything is correct in
 the package side.


Just to clarify, I am building with Debian's gcc-4.6 (4.6.1-6) from i386/sid.

 It's basically the same bug than #629819 (crti.o, crt1.o), but for the
 headers. The same workaround, explained in NEWS.Debian.gz applies. I am
 therefore merging the bugs.


[ /usr/share/doc/libc6/NEWS.Debian.gz ]

eglibc (2.13-11) unstable; urgency=low

  Starting with the eglibc package version 2.13-5, the libraries are
  shipped in the multiarch directory /lib/$arch instead of the more
  traditional /lib.

  The toolchain in Debian has been updated to cope with that, and most
  build systems should be unaffected. If you are using a non-Debian
  toolchain to build your software and it is not able to cope with
  multiarch, you might try to pass the following option to your
  compiler:

-B/usr/lib/$arch

 -- Aurelien Jarno aure...@debian.org  Sat, 23 Jul 2011 23:42:46 +0200
[...]

Passing -B/usr/lib/$arch did not help here (for both issue
gnu/stubs-32.h and crt*.o)!

What shall I do next - report a bug against gcc-4.6 package?

- Sedat -

 --
 Aurelien Jarno                          GPG: 1024D/F1BCDB73
 aurel...@aurel32.net                 http://www.aurel32.net




--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuvqxy4rlk0u69rwt5m9u3_aw6z8hkdvpww3gp+n1ut...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-09 Thread Sedat Dilek 
On Tue, Aug 9, 2011 at 9:22 PM, Aurelien Jarno aurel...@aurel32.net wrote:
 On Tue, Aug 09, 2011 at 07:33:57PM +0200, Sedat Dilek wrote:
 On Tue, Aug 9, 2011 at 7:23 PM, Aurelien Jarno aurel...@aurel32.net wrote:
  merge 629819 637218
  thanks
 
  On Tue, Aug 09, 2011 at 05:30:33PM +0200, Sedat Dilek wrote:
  Package: libc6-dev-amd64
  Version: 2.13-16
  Severity: normal
 
  Hi,
 
  I thought this stuff is fixed?
  When building gcc-4.7 snapshot, I get again this gnu/stubs-32.h error.
 
  My build breaks like this:
  ...
  /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such
  file or directory
  compilation terminated.
 
 [...]
  $ l /usr/include/i386-linux-gnu/gnu/stubs*
  -rw-r--r-- 1 root root 624  9. Aug 15:20
  /usr/include/i386-linux-gnu/gnu/stubs-32.h
  -rw-r--r-- 1 root root 315  9. Aug 15:17 
  /usr/include/i386-linux-gnu/gnu/stubs.h
 
  stubs-32.h is only there because it's an i386 only header. The problem
  is that your compiler  is not multiarch aware. Everything is correct in
  the package side.
 

 Just to clarify, I am building with Debian's gcc-4.6 (4.6.1-6) from i386/sid.

 Without any change? gcc-4.6 from Debian is supposed to be patched, and
 should find gnu/stubs-32.h into /usr/include/i386-linux-gnu/ . It looks
 like a bug in the gcc-4.6 package. On the other hand I am not able to
 reproduce the bug with glibc 2.13-16 and gcc-4.6 4.6.1-6.


What are you doing to reproduce the issue?
Can you give an sample-script?

Can you explain how to pass -B/usr/lib/$DEB_HOST_MULTIARCH option?
Is this correct (which did not work here BTW)?

$ export CFLAGS_FOR_TARGET=-g -O2 -B/usr/lib/$DEB_HOST_MULTIARCH

Backlog from #multiarch:

[22:54:17] vorlon DEB_CPPFLAGS_APPEND=-I/usr/include
DEB_LDFLAGS_APPEND=-L/usr/lib/arm-linux-gnueabi
-Wl,-rpath-link=/usr/lib/arm-linux-gnueabi:/lib/arm-linux-gnueabi:/usr/lib
debuild -uc -us -B -aarmel

Some could force to include/look-for-libs with such settings (of
course should be adapted to i386-linux-gnu), but as far as I
understood you this is obsolete and used automagically?

I am building now GCC 4.6-20110805 Snapshot, to see if it is a problem
with GCC 4.7-20110806 Snapshot [2].

- Sedat -

[1] 
http://ftp-stud.fht-esslingen.de/Mirrors/sourceware.org/gcc/snapshots/LATEST-4.6/gcc-4.6-20110805.tar.bz2
[2] 
http://ftp-stud.fht-esslingen.de/Mirrors/sourceware.org/gcc/snapshots/LATEST-4.7/gcc-4.7-20110806.tar.bz2

 --
 Aurelien Jarno                          GPG: 1024D/F1BCDB73
 aurel...@aurel32.net                 http://www.aurel32.net




--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+iczuvlpjvmoe8tqtkzu1gqmwhh_zme1gxs6ykemvxwxif...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-09 Thread Sedat Dilek 
On Tue, Aug 9, 2011 at 9:48 PM, Jonathan Nieder jrnie...@gmail.com wrote:
 Sedat Dilek wrote:

[...]
 I've just started a new gcc build with

        $ git reset --hard origin/master
        $ git clean -fdx
        $ ./configure --prefix=$HOME/opt/gcc \
                CFLAGS_FOR_TARGET=-g -O2 -B/usr/lib/x86_64-linux-gnu
        $ make BOOT_CFLAGS=-g -O2 -B/usr/lib/x86_64-linux-gnu


Can you explain why you use CFLAGS_FOR_TARGET as configure-option only
and BOOT_CFLAGS as make-option?

Is this export not enough?

$ export CFLAGS_FOR_TARGET=-g -O2 -B/usr/lib/$DEB_HOST_MULTIARCH

- Sedat -

 Seems to be working well so far; I'm cautiously optimistic.  gcc is
 4.6.1-6, libc 2.13-16.

 If that works, next step will be to try a build on i386.  I'm
 cautiously optimistic.




--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+icZUUfU1C9hOid0nghz6apquE=wjgtadrh7dh-r3vnp__...@mail.gmail.com

Bug#637218: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

2011-08-09 Thread Sedat Dilek 
On Tue, Aug 9, 2011 at 9:32 PM, Jonathan Nieder jrnie...@gmail.com wrote:
 Aurelien Jarno wrote:

 Without any change? gcc-4.6 from Debian is supposed to be patched, and
 should find gnu/stubs-32.h into /usr/include/i386-linux-gnu/ . It looks
 like a bug in the gcc-4.6 package. On the other hand I am not able to
 reproduce the bug with glibc 2.13-16 and gcc-4.6 4.6.1-6.

 I am guessing Sedat is building gcc trunk.  The failing commands are
 using xgcc, so the relevant compiler is (unpatched) upstream gcc,
 which does not look at multiarch paths unless you tell it to.


Do I need additional patches to gcc trunk (I am using the weekly
gcc-4.7 snapshot tarballs)?
From Debian gcc-snapshot (aka gcc-4.7) package - which ones?
I heard of a gcc multiarch patchset sent to upstream from debian-gcc
team - you have an URL?

- Sedat -



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+icZUV=mojh2ou7c8mm4nm6siyju12msxsornjbazzuqbd...@mail.gmail.com

Bug#636116: Overwriting identical include header files fails from libc6-dev and libc6-dev-amd64

2011-07-31 Thread Sedat Dilek 
Package: libc6-dev
Version: 2.13-13
Severity: normal

Hi,

I upgraded to eglibc (2.13-13) and see the following error-messages:

dpkg: error processing
/var/cache/apt/archives/libc6-dev-amd64_2.13-13_i386.deb (--unpack):
 trying to overwrite '/usr/include/bits', which is also in package
libc6-dev 2.13-13

When asking on #multiarch and looking into the libc6 changelog, the
problem might occur from:

eglibc (2.13-12) unstable; urgency=low
...
  * Fix installation of biarch headers (Closes: #635685):
- Use a symlink for bits/ and gnu/ directories
...

I have de-installed all multilib stuff for now.

Regards,
- Sedat -

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-1-rt-686-pae (SMP w/1 CPU core; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-dev depends on:
ii  libc-dev-bin  2.13-13Embedded GNU C Library: Developmen
ii  libc6 2.13-13Embedded GNU C Library: Shared lib
ii  linux-libc-dev3.0.0-1Linux support headers for userspac

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]  4:4.6.1-2  GNU C compiler
ii  gcc-4.4 [c-compiler]  4.4.6-7GNU C compiler
ii  gcc-4.5 [c-compiler]  4.5.3-3The GNU C compiler
ii  gcc-4.6 [c-compiler]  4.6.1-5GNU C compiler

Versions of packages libc6-dev suggests:
pn  glibc-doc none (no description available)
pn  manpages-dev  none (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+icZUVJKEmKJPjmJYyWDwZGKs5PJN8LZyO=xfs4gdrtevw...@mail.gmail.com

Bug#622116: eglibc: patch: unrecognized option '--unified-reject-files' (wrong QUILT_PATCH_OPTS)

2011-04-10 Thread Sedat Dilek 
Package: libc6
Version: 2.11.2-11
Severity: normal
Tags: patch

Hi,

while discussing Debian BR #619963 with Edwin Török I tried to apply
two glibc/upstream patches he proposed.

By unpacking the eglibc source, I fell over:
...
Applying patches...
Applying patch locale/check-unknown-symbols.diff
patch: unrecognized option '--unified-reject-files'
patch: Try `patch --help' for more information.
Patch locale/check-unknown-symbols.diff does not apply (enforce with -f)
make: *** [/home/sd/src/eglibc/eglibc-2.11.2/stamp-dir/patch] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1329:
dpkg-buildpackage -rfakeroot -d -us -uc failed

What's the help of patch saying?

$ patch --help | grep reject-format
  --reject-format=FORMAT  Create 'context' or 'unified' rejects.

BTW, patch has (2.6.1-1) version here.

So, I started my investigations and checked debian/quiltrc and changed:

-QUILT_PATCH_OPTS=--unified-reject-files
+QUILT_PATCH_OPTS=--reject-format=unified

This lets debuild apply patches again.

Regards,
- Sedat -

P.S.: Patch quiltrc.diff attached

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.39-rc2-next20110408.4-686-small (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.11.2-11  Embedded GNU C Library: Binaries
ii  libgcc1   1:4.6.0-2  GCC support library

Versions of packages libc6 recommends:
ii  libc6-i6862.11.2-11  Embedded GNU C Library: Shared lib

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0] 1.5.38 Debian configuration management sy
pn  glibc-doc none (no description available)
ii  locales   2.11.2-11  Embedded GNU C Library: National L

-- debconf information:
* glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: cups cron
--- debian/quiltrc.orig	2011-04-10 11:48:36.0 +0200
+++ debian/quiltrc	2011-04-10 12:08:43.696587720 +0200
@@ -1,4 +1,4 @@
 QUILT_PATCHES=debian/patches
-QUILT_PATCH_OPTS=--unified-reject-files
+QUILT_PATCH_OPTS=--reject-format=unified
 QUILT_DIFF_ARGS=--no-timestamps --no-index
 QUILT_REFRESH_ARGS=-pab --no-timestamps --no-index --diffstat

Bug#622116: eglibc: patch: unrecognized option '--unified-reject-files' (wrong QUILT_PATCH_OPTS)

2011-04-10 Thread Sedat Dilek 
On Sun, Apr 10, 2011 at 1:04 PM, Jonathan Nieder jrnie...@gmail.com wrote:
 unarchive 612540
 forcemerge 612540 622116
 quit

 Hi,

 Sedat Dilek wrote:

 -QUILT_PATCH_OPTS=--unified-reject-files
 +QUILT_PATCH_OPTS=--reject-format=unified

 Thanks for reporting.  Should be fixed in 2.11.2-12.


Thanks for the rocket-fast reply.

Has eglibc (2.11.2-12) ever been released or it is going to be released?

I see a Closes #612540 in eglibc/experimental (2.13-0exp5):
...
[ Clint Adams ]
   * Patch from Nobuhiro Iwamatsu to cope with the removal of
 patch --unified-reject-files.  closes: #612540.

Can you enlighten what will be next version of eglibc in sid? 2.13?
Can someone switch/jump to it w/o (big, any) concerns?

- Sedat -

[1] eglibc (2.11.2-12)



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikoo69q3wf7i-aczsowtlyz1mk...@mail.gmail.com

Bug#526823: [glibc] DNS problems with version = (2.9-8) - Can you provide i386 packages for testing?

2009-05-04 Thread Sedat Dilek 
Hi Aurelien,

since upgrading to glibc (2.9-8) and higher I have serious DNS problems.
Using OpenDNS dns-servers [1] and adding single-request to
/etc/resolv.conf did *not* help.

For amd64 arch you provided deb-files, can you offer packages for i386?

Is it possible to re-add glibc (2.9-7) back to the mirrors or give a
web-link where I can download it?

Thanks in advance.

Kind Regards,
Sedat

[1] Use OpenDNS
https://www.opendns.com/start/



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org