[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Fri, Oct 14, 2011 at 9:44 PM, Jonathan Nieder <jrnieder@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.

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 -

Reply to: