NetBSD Problem Report #48638

From martin@aprisoft.de  Tue Mar  4 09:39:52 2014
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 2BE09A62E0
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  4 Mar 2014 09:39:52 +0000 (UTC)
Message-Id: <20140304093941.583DEED0AED@emmas.aprisoft.de>
Date: Tue,  4 Mar 2014 10:39:41 +0100 (CET)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: gcc4.8 does not support MKREPRO
X-Send-Pr-Version: 3.95

>Number:         48638
>Category:       toolchain
>Synopsis:       gcc 4.8 does not support MKREPRO
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 04 09:40:01 +0000 2014
>Closed-Date:    Wed Jan 27 14:22:57 +0000 2016
>Last-Modified:  Wed Jan 27 14:22:57 +0000 2016
>Originator:     Martin Husemann
>Release:        NetBSD 6.99.30
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD whoever-brings-the-night.aprisoft.de 6.99.30 NetBSD 6.99.30 (WHOEVER) #106: Thu Jan 30 21:52:06 CET 2014 martin@emmas.aprisoft.de:/usr/src/sys/arch/sparc64/compile/WHOEVER sparc64
Architecture: sparc64
Machine: sparc64
>Description:
gcc 4.8 does not support -iremap, so MKREPRO builds do not work.

>How-To-Repeat:
build.sh -V HAVE_GCC=48  -V MKREPRO=yes

>Fix:
n/a

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->closed
State-Changed-By: christos@NetBSD.org
State-Changed-When: Fri, 18 Dec 2015 22:06:27 -0500
State-Changed-Why:
seems to work for me.


From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: christos@NetBSD.org, martin@NetBSD.org
Subject: Re: toolchain/48638 (gcc 4.8 does not support MKREPRO)
Date: Tue, 22 Dec 2015 10:36:35 +0100

 On Sat, Dec 19, 2015 at 03:06:27AM +0000, christos@NetBSD.org wrote:
 > Synopsis: gcc 4.8 does not support MKREPRO
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: christos@NetBSD.org
 > State-Changed-When: Fri, 18 Dec 2015 22:06:27 -0500
 > State-Changed-Why:
 > seems to work for me.

 I don't know if this is the right bug report for this, but currently,
 the source directory and build directories are both included in the
 binaries, and I think it's primarily the compiler that's usually used
 to sanitize this.

 As example, here's the diffoscope output for /bin/ls built into
 different target directories. Please note that both the source and
 destination directories are included in the binary!

 These should be sanitizied to /usr/src and /usr/obj when using
 MKREPRO.


 --- /archive/build/mkrepro/build-20151221-3/amd64.gcc.20151221/bin/ls
 +++ /archive/build/mkrepro/build-20151221-4/amd64.gcc.20151222/bin/ls
 ├── readelf -W --debug-dump {}
 │ @@ -8171,16 +8171,16 @@
 │    Opcode 9 has 1 args
 │    Opcode 10 has 0 args
 │    Opcode 11 has 0 args
 │    Opcode 12 has 1 args
 │  
 │   The Directory Table:
 │    /archive/foreign/src/bin/ls
 │ -  /archive/build/amd64.gcc.20151221/usr/include/sys
 │ -  /archive/build/amd64.gcc.20151221/usr/include
 │ +  /archive/build/amd64.gcc.20151222/usr/include/sys
 │ +  /archive/build/amd64.gcc.20151222/usr/include
 │  
 │   The File Name Table:
 │    Entry	Dir	Time	Size	Name
 │    1	1	0	0	cmp.c
 │    2	2	0	0	common_int_types.h
 │    3	2	0	0	ansi.h
 │    4	2	0	0	types.h
 │ @@ -8320,17 +8320,17 @@
 │    Opcode 9 has 1 args
 │    Opcode 10 has 0 args
 │    Opcode 11 has 0 args
 │    Opcode 12 has 1 args
 │  
 │   The Directory Table:
 │    /archive/foreign/src/bin/ls
 │ -  /archive/build/amd64.gcc.20151221/usr/include/sys
 │ -  /archive/build/amd64.gcc.20151221/usr/include
 │ -  /archive/build/amd64.gcc.20151221/usr/include/machine
 │ +  /archive/build/amd64.gcc.20151222/usr/include/sys
 │ +  /archive/build/amd64.gcc.20151222/usr/include
 │ +  /archive/build/amd64.gcc.20151222/usr/include/machine
 │  
 │   The File Name Table:
 │    Entry	Dir	Time	Size	Name
 │    1	1	0	0	ls.c
 │    2	2	0	0	common_int_types.h
 │    3	2	0	0	ansi.h
 │    4	2	0	0	types.h
 │ @@ -8985,17 +8985,17 @@
 │    Opcode 9 has 1 args
 │    Opcode 10 has 0 args
 │    Opcode 11 has 0 args
 │    Opcode 12 has 1 args
 │  
 │   The Directory Table:
 │    /archive/foreign/src/bin/ls
 │ -  /archive/build/amd64.gcc.20151221/usr/include
 │ -  /archive/build/amd64.gcc.20151221/usr/include/sys
 │ -  /archive/build/amd64.gcc.20151221/usr/include/machine
 │ +  /archive/build/amd64.gcc.20151222/usr/include
 │ +  /archive/build/amd64.gcc.20151222/usr/include/sys
 │ +  /archive/build/amd64.gcc.20151222/usr/include/machine
 │  
 │   The File Name Table:
 │    Entry	Dir	Time	Size	Name
 │    1	1	0	0	print.c
 │    2	2	0	0	stdio.h
 │    3	3	0	0	common_int_types.h
 │    4	3	0	0	common_int_mwgwtypes.h
 │ @@ -9793,16 +9793,16 @@
 │    Opcode 9 has 1 args
 │    Opcode 10 has 0 args
 │    Opcode 11 has 0 args
 │    Opcode 12 has 1 args
 │  
 │   The Directory Table:
 │    /archive/foreign/src/bin/ls
 │ -  /archive/build/amd64.gcc.20151221/usr/include/sys
 │ -  /archive/build/amd64.gcc.20151221/usr/include
 │ +  /archive/build/amd64.gcc.20151222/usr/include/sys
 │ +  /archive/build/amd64.gcc.20151222/usr/include
 │  
 │   The File Name Table:
 │    Entry	Dir	Time	Size	Name
 │    1	1	0	0	util.c
 │    2	2	0	0	common_int_types.h
 │    3	2	0	0	ansi.h
 │    4	2	0	0	types.h
 ├── objdump --disassemble --full-contents {}
 │ @@ -2647,18 +2647,18 @@
 │   0a60 133c1900 0000                        .<....          
 │  Contents of section .debug_line:
 │   0000 8d010000 0200f000 00000101 fb0e0d00  ................
 │   0010 01010101 00000001 0000012f 61726368  .........../arch
 │   0020 6976652f 666f7265 69676e2f 7372632f  ive/foreign/src/
 │   0030 62696e2f 6c73002f 61726368 6976652f  bin/ls./archive/
 │   0040 6275696c 642f616d 6436342e 6763632e  build/amd64.gcc.
 │ - 0050 32303135 31323231 2f757372 2f696e63  20151221/usr/inc
 │ + 0050 32303135 31323232 2f757372 2f696e63  20151222/usr/inc
 │   0060 6c756465 2f737973 002f6172 63686976  lude/sys./archiv
 │   0070 652f6275 696c642f 616d6436 342e6763  e/build/amd64.gc
 │ - 0080 632e3230 31353132 32312f75 73722f69  c.20151221/usr/i
 │ + 0080 632e3230 31353132 32322f75 73722f69  c.20151222/usr/i
 │   0090 6e636c75 64650000 636d702e 63000100  nclude..cmp.c...
 │   00a0 00636f6d 6d6f6e5f 696e745f 74797065  .common_int_type
 │   00b0 732e6800 02000061 6e73692e 68000200  s.h....ansi.h...
 │   00c0 00747970 65732e68 00020000 74696d65  .types.h....time
 │   00d0 73706563 2e680002 00007374 61742e68  spec.h....stat.h
 │   00e0 00020000 6674732e 68000300 00737472  ....fts.h....str
 │   00f0 696e672e 68000300 00000009 02301740  ing.h........0.@
 │ @@ -2672,21 +2672,21 @@
 │   0170 66140822 03907f2e 03ef00c8 685b2414  f.."........h[$.
 │   0180 0822038b 7f2e03f6 00f25b1b 02060001  ."........[.....
 │   0190 01da0400 000200bd 01000001 01fb0e0d  ................
 │   01a0 00010101 01000000 01000001 2f617263  ............/arc
 │   01b0 68697665 2f666f72 6569676e 2f737263  hive/foreign/src
 │   01c0 2f62696e 2f6c7300 2f617263 68697665  /bin/ls./archive
 │   01d0 2f627569 6c642f61 6d643634 2e676363  /build/amd64.gcc
 │ - 01e0 2e323031 35313232 312f7573 722f696e  .20151221/usr/in
 │ + 01e0 2e323031 35313232 322f7573 722f696e  .20151222/usr/in
 │   01f0 636c7564 652f7379 73002f61 72636869  clude/sys./archi
 │   0200 76652f62 75696c64 2f616d64 36342e67  ve/build/amd64.g
 │ - 0210 63632e32 30313531 3232312f 7573722f  cc.20151221/usr/
 │ + 0210 63632e32 30313531 3232322f 7573722f  cc.20151222/usr/
 │   0220 696e636c 75646500 2f617263 68697665  include./archive
 │   0230 2f627569 6c642f61 6d643634 2e676363  /build/amd64.gcc
 │ - 0240 2e323031 35313232 312f7573 722f696e  .20151221/usr/in
 │ + 0240 2e323031 35313232 322f7573 722f696e  .20151222/usr/in
 │   0250 636c7564 652f6d61 6368696e 6500006c  clude/machine..l
 │   0260 732e6300 01000063 6f6d6d6f 6e5f696e  s.c....common_in
 │   0270 745f7479 7065732e 68000200 00616e73  t_types.h....ans
 │   0280 692e6800 02000074 79706573 2e680002  i.h....types.h..
 │   0290 00007469 6d657370 65632e68 00020000  ..timespec.h....
 │   02a0 73746174 2e680002 00007474 79636f6d  stat.h....ttycom
 │   02b0 2e680002 00006674 732e6800 03000073  .h....fts.h....s
 │ @@ -2756,21 +2756,21 @@
 │   06b0 00657874 65726e2e 68000100 00000009  .extern.h.......
 │   06c0 02884040 00000000 00032f01 14020500  ..@@....../.....
 │   06d0 01012306 00000200 a5010000 0101fb0e  ..#.............
 │   06e0 0d000101 01010000 00010000 012f6172  ............./ar
 │   06f0 63686976 652f666f 72656967 6e2f7372  chive/foreign/sr
 │   0700 632f6269 6e2f6c73 002f6172 63686976  c/bin/ls./archiv
 │   0710 652f6275 696c642f 616d6436 342e6763  e/build/amd64.gc
 │ - 0720 632e3230 31353132 32312f75 73722f69  c.20151221/usr/i
 │ + 0720 632e3230 31353132 32322f75 73722f69  c.20151222/usr/i
 │   0730 6e636c75 6465002f 61726368 6976652f  nclude./archive/
 │   0740 6275696c 642f616d 6436342e 6763632e  build/amd64.gcc.
 │ - 0750 32303135 31323231 2f757372 2f696e63  20151221/usr/inc
 │ + 0750 32303135 31323232 2f757372 2f696e63  20151222/usr/inc
 │   0760 6c756465 2f737973 002f6172 63686976  lude/sys./archiv
 │   0770 652f6275 696c642f 616d6436 342e6763  e/build/amd64.gc
 │ - 0780 632e3230 31353132 32312f75 73722f69  c.20151221/usr/i
 │ + 0780 632e3230 31353132 32322f75 73722f69  c.20151222/usr/i
 │   0790 6e636c75 64652f6d 61636869 6e650000  nclude/machine..
 │   07a0 7072696e 742e6300 01000073 7464696f  print.c....stdio
 │   07b0 2e680002 0000636f 6d6d6f6e 5f696e74  .h....common_int
 │   07c0 5f747970 65732e68 00030000 636f6d6d  _types.h....comm
 │   07d0 6f6e5f69 6e745f6d 77677774 79706573  on_int_mwgwtypes
 │   07e0 2e680003 0000616e 73692e68 00030000  .h....ansi.h....
 │   07f0 74797065 732e6800 03000074 696d6573  types.h....times
 │ @@ -2855,18 +2855,18 @@
 │   0ce0 74890402 038701e4 0401038c 7f9e0402  t...............
 │   0cf0 03f4009e 02050001 01980100 0002000c  ................
 │   0d00 01000001 01fb0e0d 00010101 01000000  ................
 │   0d10 01000001 2f617263 68697665 2f666f72  ..../archive/for
 │   0d20 6569676e 2f737263 2f62696e 2f6c7300  eign/src/bin/ls.
 │   0d30 2f617263 68697665 2f627569 6c642f61  /archive/build/a
 │   0d40 6d643634 2e676363 2e323031 35313232  md64.gcc.2015122
 │ - 0d50 312f7573 722f696e 636c7564 652f7379  1/usr/include/sy
 │ + 0d50 322f7573 722f696e 636c7564 652f7379  2/usr/include/sy
 │   0d60 73002f61 72636869 76652f62 75696c64  s./archive/build
 │   0d70 2f616d64 36342e67 63632e32 30313531  /amd64.gcc.20151
 │ - 0d80 3232312f 7573722f 696e636c 75646500  221/usr/include.
 │ + 0d80 3232322f 7573722f 696e636c 75646500  222/usr/include.
 │   0d90 00757469 6c2e6300 01000063 6f6d6d6f  .util.c....commo
 │   0da0 6e5f696e 745f7479 7065732e 68000200  n_int_types.h...
 │   0db0 00616e73 692e6800 02000074 79706573  .ansi.h....types
 │   0dc0 2e680002 00007374 64696f2e 68000300  .h....stdio.h...
 │   0dd0 00737464 6c69622e 68000300 00776368  .stdlib.h....wch
 │   0de0 61722e68 00030000 6c732e68 00010000  ar.h....ls.h....
 │   0df0 7669732e 68000300 00657272 2e680003  vis.h....err.h..
 ╵

State-Changed-From-To: closed->open
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Tue, 22 Dec 2015 10:28:49 +0000
State-Changed-Why:
reopen for now.


From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: re: toolchain/48638 (gcc 4.8 does not support MKREPRO)
Date: Wed, 23 Dec 2015 01:44:20 +1100

 hmmm.

 the only real way i know to solve this is to only use relative paths
 for pretty much everything.

 that's ugly in several ways, and also doesn't work well with some of
 the supported build methods we have (eg, various objdir methods.)

 i'm not sure i think we should fix this part, but instead always
 build in a chroot such that the paths are well known.  it's really
 the only safe way to make sure *ALL* tools use the right paths.
 i'm sure GCC isn't the only problem here, and new cases appear.


 .mrg.

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: toolchain/48638 (gcc 4.8 does not support MKREPRO)
Date: Tue, 22 Dec 2015 18:33:22 +0100

 On Tue, Dec 22, 2015 at 09:40:01AM +0000, Thomas Klausner wrote:
 >  As example, here's the diffoscope output for /bin/ls built into
 >  different target directories. Please note that both the source and
 >  destination directories are included in the binary!

 Is that with or without debug data?

 Joerg

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, toolchain-manager@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Cc: 
Subject: Re: toolchain/48638 (gcc 4.8 does not support MKREPRO)
Date: Tue, 22 Dec 2015 13:07:57 -0500

 On Dec 22,  5:35pm, joerg@britannica.bec.de (Joerg Sonnenberger) wrote:
 -- Subject: Re: toolchain/48638 (gcc 4.8 does not support MKREPRO)

 |  On Tue, Dec 22, 2015 at 09:40:01AM +0000, Thomas Klausner wrote:
 |  >  As example, here's the diffoscope output for /bin/ls built into
 |  >  different target directories. Please note that both the source and
 |  >  destination directories are included in the binary!
 |  
 |  Is that with or without debug data?

 This info is in ls.debug... Anyway, I fixed it.

 christos

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/48638 (gcc 4.8 does not support MKREPRO)
Date: Thu, 31 Dec 2015 01:13:48 +0000

 On Tue, Dec 22, 2015 at 02:45:01PM +0000, matthew green wrote:
  >  the only real way i know to solve this is to only use relative paths
  >  for pretty much everything.
  >  
  >  that's ugly in several ways, and also doesn't work well with some of
  >  the supported build methods we have (eg, various objdir methods.)
  >  
  >  i'm not sure i think we should fix this part, but instead always
  >  build in a chroot such that the paths are well known.  it's really
  >  the only safe way to make sure *ALL* tools use the right paths.
  >  i'm sure GCC isn't the only problem here, and new cases appear.

 Build systems should always use only relative paths, for this precise
 reason :-)  but getting there isn't trivial.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: open->feedback
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Wed, 27 Jan 2016 14:02:15 +0000
State-Changed-Why:
Works for me, do you have anything remaining?


State-Changed-From-To: feedback->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Wed, 27 Jan 2016 14:22:57 +0000
State-Changed-Why:
All fine from my POV


>Unformatted:

Home	PR Database Search