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

Re: What about a non-free compiler? (Re: new port: debian-win32. when ?)



Colin Watson wrote:
> 
> 
> We shouldn't be distributing package binaries with Debian that are
> compiled with some commercial tool not available to others. If both I
> and the package distributor have current versions of the relevant
> development packages, I must be able to compile the sources myself and
> arrive at exactly the same result. Anything else makes it difficult,
> sometimes impossible, to adequately test fixes that I may want to
> contribute back to the package, and I think this is unacceptable.
> 

I guess you're referring to subtleties caused by the compiler
implementation, slightly different binary file format handling,
and the mysterious troubles that might be caused. For instance,
gcc might output A for a, while the proprietary compiler outputs
A', while A and A' must carry the same semantics A doesn't
compile due to an error in library linkage but A' works perfectly.
The gcc user has to figure out why it didn't work. But I was suggesting
that we assume the proprietary compiler is a drop-in replacement
for gcc to produce Linux ELF binaries, etc.And compilation
with gcc is also tested, and the new compiled binary is optional.
That is primary packages are done on gcc, but optimized
binaries are created with the proprietary compiler. After all, I was
only fantasizing, I'm trying to find out whether this makes sense.

> For instance, what if your expensive non-free, non-distributable
> compiler had a bug? It's not uncommon: I have an outstanding bug against
> gcc right now for compiling one of my unofficial packages wrongly. If
> you leave your users in a position where they find it difficult to tell
> whether their binary is crashing because of a bug in the source or a bug
> in the compiler, or where they can't test for themselves if a patch
> they've written and painstakingly tested under the freely distributed
> development tools is going to break when you compile it, then ultimately
> you're only decreasing the quality of the distribution.
> 

The case that another compiler can build your package all right, but
gcc cannot. I also think this would be unacceptable. But again,
I'd like to remind that many packages are portable themselves
and are being developed on compilers different than gcc.

> Of course, nobody's stopping you trying out non-free, non-distributable
> compilers for yourself, but let's not start using them to build
> distributed Debian packages.
>

I wonder if it would make any performance difference;
then such packages would be very valuable for a high performance
computing application. If it could achieve any performance improvement
at all, a Beowulf system would benefit a lot. On the other hand,
I was asking this question because I'm having great difficulties
with g++ as my main C++ compiler. I'm writing standard C++
code for some tasks that require efficiency and [portability], but
I'm getting very skeptical about the "GCC Steering Comittee" and
that the gcc might be becoming the Visual C of Red Hat. I know of
all the arguments about the rights and everything belonging to
FSF and that it is pure free software, but what can I do if it doesn't
satisfy my requirements? I would like to make my software into
Debian packages, and I think the right way would be to offer
the binaries with best performance. (Yes, I will put them
under GPL)

On the other hand, if g++ is becoming a conformant ISO Standard
implementation, and if its performance and compilation model
is going to surpass each and every other compiler on earth in
the following 6 months, I could wait. But that doesn't seem likely.
I'd be so glad if someone who has first hand experience with
other compilers would tell me what the best C++ compiler on Linux is.

Regards,

-- 
 ++++-+++-+++-++-++-++--+---+----+----- ---  --  -  - 
 +  Eray "eXa" Ozkural                   .      .   .  . . .
 +  CS, Bilkent University, Ankara             ^  .  o   .      .
 |  mail: erayo@cs.bilkent.edu.tr                .  ^  .


Reply to: