FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 12-30-2011, 06:08 PM
Jonathan Nieder
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

found 431014 gcc-snapshot/20111210-1
tags 431014 + wontfix
quit

Hi Adam,

Adam Borowski wrote:

> I see no reason why it couldn't simply be shipped in the package
> outright. It's not like it invades anyone's namespace, etc. It would be
> also consistent with all other gcc packages, all having the executable named
> the same as the package. At least after having tested my stuff with gcc-4.2
> in the past, I didn't even suspect gcc-snapshot could be any different until
> ./configure failed

I suspect it's to save people from the pain of using the snapshot to build
Debian packages on autobuilders when wanting to use a new feature or
after running into a bug with one of the released gcc versions.

Tagging wontfix to reflect the de facto status.

Thanks for writing,
Jonathan



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111230190824.GA12085@elie.Belkin">http://lists.debian.org/20111230190824.GA12085@elie.Belkin
 
Old 12-30-2011, 08:55 PM
Vincent Lefevre
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-30 13:08:24 -0600, Jonathan Nieder wrote:
> Adam Borowski wrote:
> > I see no reason why it couldn't simply be shipped in the package
> > outright. It's not like it invades anyone's namespace, etc. It
> > would be also consistent with all other gcc packages, all having
> > the executable named the same as the package. At least after
> > having tested my stuff with gcc-4.2 in the past, I didn't even
> > suspect gcc-snapshot could be any different until ./configure
> > failed
>
> I suspect it's to save people from the pain of using the snapshot to
> build Debian packages on autobuilders when wanting to use a new
> feature or after running into a bug with one of the released gcc
> versions.

I use gcc-snapshot as a simple end user of GCC, in order to do some
portability tests of my programs (not directly related to Debian)
with the latest GCC features, in particular. So, providing
/usr/bin/gcc-snapshot would be natural.

Do you mean that you don't want gcc-snapshot to be in /usr/bin
because this would yield problems on autobuilders? But wouldn't
be the autobuilders' fault?

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111230215536.GF5329@xvii.vinc17.org">http://lists.debian.org/20111230215536.GF5329@xvii.vinc17.org
 
Old 12-30-2011, 10:15 PM
Jonathan Nieder
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

Vincent Lefevre wrote:

> Do you mean that you don't want gcc-snapshot to be in /usr/bin
> because this would yield problems on autobuilders?

No, I mean that packagers can but should not use

Build-Depends: gcc-snapshot

CC = gcc-snapshot

"Don't do that, then." you might say. But not providing a
/usr/bin/gcc-snapshot wrapper provides people with a reminder to look
at README.Debian and not to do that.

There may be ways to make using gcc-snapshot more convenient without
that problem, of course (and well justified patches are as always
welcome).

Hope that helps,
Jonathan



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111230231500.GB19328@elie.Belkin">http://lists.debian.org/20111230231500.GB19328@elie.Belkin
 
Old 12-30-2011, 11:34 PM
Vincent Lefevre
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-30 17:15:00 -0600, Jonathan Nieder wrote:
> No, I mean that packagers can but should not use
>
> Build-Depends: gcc-snapshot
>
> CC = gcc-snapshot
>
> "Don't do that, then." you might say. But not providing a
> /usr/bin/gcc-snapshot wrapper provides people with a reminder to look
> at README.Debian and not to do that.

OK. Couldn't the wrapper detect that it is being used by a packager
(e.g. because some environment variable is set by the build process)
and output an error in such a case?

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111231003435.GG5329@xvii.vinc17.org">http://lists.debian.org/20111231003435.GG5329@xvii.vinc17.org
 
Old 12-31-2011, 03:04 PM
Matthias Klose
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 12/31/2011 01:34 AM, Vincent Lefevre wrote:
> On 2011-12-30 17:15:00 -0600, Jonathan Nieder wrote:
>> No, I mean that packagers can but should not use
>>
>> Build-Depends: gcc-snapshot
>>
>> CC = gcc-snapshot
>>
>> "Don't do that, then." you might say. But not providing a
>> /usr/bin/gcc-snapshot wrapper provides people with a reminder to look's
>> at README.Debian and not to do that.
>
> OK. Couldn't the wrapper detect that it is being used by a packager
> (e.g. because some environment variable is set by the build process)
> and output an error in such a case?

A wrapper will never remind you using the new library paths at runtime. The
snapshot package is meant to get early feedback about the development version of
GCC, either for a rebuild test, or to easily test for compiler errors on porter
boxes. It's not a package meant for regular development. I really prefer to
have users either set environment variables or create the wrapper scripts on
their own.



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EFF3283.4020907@debian.org">http://lists.debian.org/4EFF3283.4020907@debian.org
 
Old 12-31-2011, 06:24 PM
Vincent Lefevre
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-31 17:04:19 +0100, Matthias Klose wrote:
> A wrapper will never remind you using the new library paths at runtime.

At runtime? Do you mean that one needs to change the library path
also for running the generated executable? The README.Debian file
doesn't say anything like that. According to the README.Debian
file, the wrapper is just what we need.

> The snapshot package is meant to get early feedback about the
> development version of GCC, either for a rebuild test, or to easily
> test for compiler errors on porter boxes. It's not a package meant
> for regular development. I really prefer to have users either set
> environment variables or create the wrapper scripts on their own.

The package description doesn't say that it isn't for regular
development.

BTW, is there any reason why gcc-snapshot needs the library path
to be changed explicitly (to run the compiler) while this is not
needed for gcc-4.4, gcc-4.5, etc.?

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111231192441.GJ5329@xvii.vinc17.org">http://lists.debian.org/20111231192441.GJ5329@xvii.vinc17.org
 
Old 12-31-2011, 07:00 PM
Jonathan Nieder
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

Vincent Lefevre wrote:

> At runtime? Do you mean that one needs to change the library path
> also for running the generated executable?

Yes, gcc-snapshot includes a snapshot of libgcc (and libstdc++,
libgcj, libobjc, etc). So checking those libraries' behavior involves
modifying the library path at runtime.

>From time to time the ABI can be bumped, which means the dependencies
of generated executables need not always be satisfied by the ordinary
copies of those libraries in /lib.

> The README.Debian file
> doesn't say anything like that. According to the README.Debian
> file, the wrapper is just what we need.

Good catch, thanks. Can you suggest an improved wording?

[...]
> BTW, is there any reason why gcc-snapshot needs the library path
> to be changed explicitly (to run the compiler) while this is not
> needed for gcc-4.4, gcc-4.5, etc.?

The libraries in gcc-snapshot are private libraries, not meant to
conflict with the libgcc1 et al packages nor to be used by ordinary
programs like /bin/ls except when the user requests so by setting
LD_LIBRARY_PATH.

Cheers,
Jonathan



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111231200004.GA19577@elie.Belkin">http://lists.debian.org/20111231200004.GA19577@elie.Belkin
 
Old 12-31-2011, 08:43 PM
Vincent Lefevre
 
Default Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-31 14:00:04 -0600, Jonathan Nieder wrote:
> Vincent Lefevre wrote:
>
> > At runtime? Do you mean that one needs to change the library path
> > also for running the generated executable?
>
> Yes, gcc-snapshot includes a snapshot of libgcc (and libstdc++,
> libgcj, libobjc, etc). So checking those libraries' behavior involves
> modifying the library path at runtime.

OK, I thought that the static version was used in such a case, but
I've now seen that the gcc doc (under -static-libgcc) says that it
is not always possible (in particular for C++ and Java).

Alternatively, couldn't /usr/lib/gcc-snapshot/lib be added to the
run path instead of having to use LD_LIBRARY_PATH? For instance,
having

export LD_RUN_PATH=/usr/lib/gcc-snapshot/lib

in the gcc-snapshot wrapper seems to work (I've done tests with mksh).

Without this run path setting:

$ ldd mksh
linux-vdso.so.1 => (0x00007fff829ff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f159516a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1594f54000)
/lib64/ld-linux-x86-64.so.2 (0x00007f159550d000)

With this setting:

$ ldd mksh
linux-vdso.so.1 => (0x00007fff69fff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f85a6818000)
libgcc_s.so.1 => /usr/lib/gcc-snapshot/lib/libgcc_s.so.1 (0x00007f85a6603000)
/lib64/ld-linux-x86-64.so.2 (0x00007f85a6bbb000)

without modifying LD_LIBRARY_PATH.

> From time to time the ABI can be bumped, which means the dependencies
> of generated executables need not always be satisfied by the ordinary
> copies of those libraries in /lib.

I also suppose that there may be incompatilibities if the software
compiled with gcc-snapshot is linked against libraries compiled with
normal GCC versions (if they both use libgcc).

> > The README.Debian file
> > doesn't say anything like that. According to the README.Debian
> > file, the wrapper is just what we need.
>
> Good catch, thanks. Can you suggest an improved wording?

Let's first see what you think about the run path...

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111231214308.GK5329@xvii.vinc17.org">http://lists.debian.org/20111231214308.GK5329@xvii.vinc17.org
 

Thread Tools




All times are GMT. The time now is 02:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org