unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS)
       [not found] <20110404090605.9635.62532.reportbug@virgil.dodds.net>
@ 2011-04-14  3:56 ` Rob Browning
  2011-04-14  4:46   ` bug#8497: " Eli Zaretskii
  2011-04-16  1:51   ` Glenn Morris
  0 siblings, 2 replies; 6+ messages in thread
From: Rob Browning @ 2011-04-14  3:56 UTC (permalink / raw)
  To: bug-gnu-emacs; +Cc: Steve Langasek, 620795, 620795-forwarded


(If possible, please preserve the 620795-forwarded address in any replies.)

Debian is likely to migrate to multiarch, and it appears that the
transition will probably break the Emacs build process.

The problem is that Emacs uses cpp to process the Makefiles, and with
multiarch, include paths will include strings like "i386" that cpp will
replace with nonsensical values. i.e.

  -I/usr/lib/i386-linux-gnu/glib-2.0 -> -I/usr/lib/1-linux-gnu/glib-2.0

Steve Langasek <steve.langasek@canonical.com> writes:

> Having begun to convert libraries over to multiarch in Ubuntu, we've found
> emacs23 among the packages which fails to build.  This is because the
> two-stage, autoconf+cpp generation of src/Makefile and lib-src/Makefile
> results in strings like "-I/usr/lib/i386-linux-gnu/glib-2.0" being seen as
> input to cpp... which has "i386" as a macro defined to "1".  So unless these
> macros are undefined, the path that winds up in the Makefile is broken and
> results in a build failure.
>
> The attached patch partially addresses this by undefining any macros that
> happen to exist for the <cpu> portion of the architecture triplet.  Only
> architectures for which Ubuntu currently builds are handled here, however;
> for Debian either a more comprehensive list or a generic fix is needed. 
> It's possible that passing -fdirectives-only to cpp would solve this, but I
> haven't tested.

Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620795 for
additional information.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4




^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8497: Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS)
  2011-04-14  3:56 ` Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS) Rob Browning
@ 2011-04-14  4:46   ` Eli Zaretskii
  2011-04-16  1:51   ` Glenn Morris
  1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2011-04-14  4:46 UTC (permalink / raw)
  To: Rob Browning; +Cc: 620795-forwarded, 8497-done, steve.langasek, 620795

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Wed, 13 Apr 2011 22:56:03 -0500
> Cc: 620795-forwarded@bugs.debian.org,
> 	Steve Langasek <steve.langasek@canonical.com>, 620795@bugs.debian.org
> 
> 
> (If possible, please preserve the 620795-forwarded address in any replies.)
> 
> Debian is likely to migrate to multiarch, and it appears that the
> transition will probably break the Emacs build process.
> 
> The problem is that Emacs uses cpp to process the Makefiles

It no longer does in the development trunk.  However, that change is
not (and probably will not be) in the emacs-23 release branch, only in
Emacs 24 when that is released.

So I'm closing this bug.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8497: Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS)
  2011-04-14  3:56 ` Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS) Rob Browning
  2011-04-14  4:46   ` bug#8497: " Eli Zaretskii
@ 2011-04-16  1:51   ` Glenn Morris
  2011-04-16  2:12     ` Steve Langasek
  1 sibling, 1 reply; 6+ messages in thread
From: Glenn Morris @ 2011-04-16  1:51 UTC (permalink / raw)
  To: Rob Browning; +Cc: Steve Langasek, 8497

Rob Browning wrote:

> (If possible, please preserve the 620795-forwarded address in any replies.)

Sorry, not so long as bug#63995 exists.

>> The attached patch partially addresses this by undefining any macros that
>> happen to exist for the <cpu> portion of the architecture triplet.

Note the following in configure.in attempts to do this kind of thing already:

    # Now get this: Some word that is part of the ${srcdir} directory name
    # or the ${configuration} value might, just might, happen to be an
    # identifier like `sun4' or `i386' or something, and be predefined by
    # the C preprocessor to some helpful value like 1, or maybe the empty
    # string.  Needless to say consequent macro substitutions are less
    # than conducive to the makefile finding the correct directory.
    [cpp_undefs="`echo $srcdir $configuration $canonical unix |
      sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/  *$//' \
      -e 's/  */ -U/g' -e 's/-U[0-9][^ ]*//g'`"]


so it's not obvious to me why you need to do more (maybe $canonical is
i686-something but your directories are i386-something?).





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8497: Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS)
  2011-04-16  1:51   ` Glenn Morris
@ 2011-04-16  2:12     ` Steve Langasek
  2011-04-16 16:29       ` Rob Browning
  2011-04-17 17:35       ` Rob Browning
  0 siblings, 2 replies; 6+ messages in thread
From: Steve Langasek @ 2011-04-16  2:12 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Rob Browning, 8497

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

On Fri, Apr 15, 2011 at 09:51:00PM -0400, Glenn Morris wrote:
> Rob Browning wrote:

> > (If possible, please preserve the 620795-forwarded address in any replies.)

> Sorry, not so long as bug#63995 exists.

> >> The attached patch partially addresses this by undefining any macros that
> >> happen to exist for the <cpu> portion of the architecture triplet.

> Note the following in configure.in attempts to do this kind of thing already:

>     # Now get this: Some word that is part of the ${srcdir} directory name
>     # or the ${configuration} value might, just might, happen to be an
>     # identifier like `sun4' or `i386' or something, and be predefined by
>     # the C preprocessor to some helpful value like 1, or maybe the empty
>     # string.  Needless to say consequent macro substitutions are less
>     # than conducive to the makefile finding the correct directory.
>     [cpp_undefs="`echo $srcdir $configuration $canonical unix |
>       sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/  *$//' \
>       -e 's/  */ -U/g' -e 's/-U[0-9][^ ]*//g'`"]

> so it's not obvious to me why you need to do more (maybe $canonical is
> i686-something but your directories are i386-something?).

Ah - yes, that's exactly right.  So this issue should only affect the i386
build, where the toolchain triplet != the multiarch directory.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8497: Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS)
  2011-04-16  2:12     ` Steve Langasek
@ 2011-04-16 16:29       ` Rob Browning
  2011-04-17 17:35       ` Rob Browning
  1 sibling, 0 replies; 6+ messages in thread
From: Rob Browning @ 2011-04-16 16:29 UTC (permalink / raw)
  To: Steve Langasek; +Cc: 8497

Steve Langasek <steve.langasek@canonical.com> writes:

> On Fri, Apr 15, 2011 at 09:51:00PM -0400, Glenn Morris wrote:
>> Rob Browning wrote:
>
>> > (If possible, please preserve the 620795-forwarded address in any replies.)
>
>> Sorry, not so long as bug#63995 exists.
>
>> >> The attached patch partially addresses this by undefining any macros that
>> >> happen to exist for the <cpu> portion of the architecture triplet.
>
>> Note the following in configure.in attempts to do this kind of thing already:
>
>>     # Now get this: Some word that is part of the ${srcdir} directory name
>>     # or the ${configuration} value might, just might, happen to be an
>>     # identifier like `sun4' or `i386' or something, and be predefined by
>>     # the C preprocessor to some helpful value like 1, or maybe the empty
>>     # string.  Needless to say consequent macro substitutions are less
>>     # than conducive to the makefile finding the correct directory.
>>     [cpp_undefs="`echo $srcdir $configuration $canonical unix |
>>       sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/  *$//' \
>>       -e 's/  */ -U/g' -e 's/-U[0-9][^ ]*//g'`"]
>
>> so it's not obvious to me why you need to do more (maybe $canonical is
>> i686-something but your directories are i386-something?).
>
> Ah - yes, that's exactly right.  So this issue should only affect the i386
> build, where the toolchain triplet != the multiarch directory.

OK, thanks.  I'll fix that in the next Debian release.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8497: Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS)
  2011-04-16  2:12     ` Steve Langasek
  2011-04-16 16:29       ` Rob Browning
@ 2011-04-17 17:35       ` Rob Browning
  1 sibling, 0 replies; 6+ messages in thread
From: Rob Browning @ 2011-04-17 17:35 UTC (permalink / raw)
  To: Steve Langasek; +Cc: 8497

Steve Langasek <steve.langasek@canonical.com> writes:

> On Fri, Apr 15, 2011 at 09:51:00PM -0400, Glenn Morris wrote:

>> Note the following in configure.in attempts to do this kind of thing already:
>
>>     # Now get this: Some word that is part of the ${srcdir} directory name
>>     # or the ${configuration} value might, just might, happen to be an
>>     # identifier like `sun4' or `i386' or something, and be predefined by
>>     # the C preprocessor to some helpful value like 1, or maybe the empty
>>     # string.  Needless to say consequent macro substitutions are less
>>     # than conducive to the makefile finding the correct directory.
>>     [cpp_undefs="`echo $srcdir $configuration $canonical unix |
>>       sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/  *$//' \
>>       -e 's/  */ -U/g' -e 's/-U[0-9][^ ]*//g'`"]
>
>> so it's not obvious to me why you need to do more (maybe $canonical is
>> i686-something but your directories are i386-something?).
>
> Ah - yes, that's exactly right.  So this issue should only affect the i386
> build, where the toolchain triplet != the multiarch directory.

For now I've fixed this for the next upload by just adding a hard-coded
i386 after "unix".

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-04-17 17:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20110404090605.9635.62532.reportbug@virgil.dodds.net>
2011-04-14  3:56 ` Bug#620795: emacs23: Makefile generation with cpp mangles multiarch include paths (impending FTBFS) Rob Browning
2011-04-14  4:46   ` bug#8497: " Eli Zaretskii
2011-04-16  1:51   ` Glenn Morris
2011-04-16  2:12     ` Steve Langasek
2011-04-16 16:29       ` Rob Browning
2011-04-17 17:35       ` Rob Browning

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).