[prev] [thread] [next] [lurker] [Date index for 2006/04/16]
On Thu, 13 Apr 2006 23:38:44 +0300, Jarkko Hietaniemi <jhietaniemi@xxxxx.xxx>
wrote:
> Sean 'Captain Napalm' Conner wrote:
> >> and don't even get me started on trying
> >> to configure compile any of that stuff outside Linux. Just thinking
> >> about GNU configure and the GNU autotools make me see horrible violent
> >> visions through blood-red haze. Making software portable my ass.
> >
> > What I hate about GNU configure is that nothing is ever cached so every
> > package I do "./configure" has to run a bazillion tests to see what type of
> > compiler and header files I have---can't it just do that *once* when I
> > install the system?
That is what imake does. And I hates that too.
One *big*^w*huge* advantage of configure being run over and over again is
that it adapts to a dynamic system where things get installed and updated.
The other is that one can set a $CONFIG_SITE (what a terrible name btw) to
define the machine specific settings, and so catch special env calls.
Some products are too linux-centric, and *need* to be built with gcc. They
just refuse to be built with the native C compiler. As I prefer the latter,
because of performance, I sometimes have to refuge to gcc
# configure --prefix=/foo/bar --disable-nls
vs
# env CC=gcc configure --prefix=/foo/bar --disable-nls
> > Sigh.
>
> Sigh and amen, brother.
>
> >>> But glib does not allow to be configured without NLS, hence requires gettext
> >>> and libintl, two of the most stupid extentions ever invented to make software
> >>> portable. --disable-nls should be the default, and supported by every single
> >> On that I can agree. They are prime WTFWTT (What The Fuck Where They
> >> Thinking) software.
> >
> > Guess I'm lucky in not having to deal directly with that. What exactly,
> > *is* so bad about gettext and libintl? Or will I regret asking?
>
> You asking from the sysadmin viewpoint or from the developer viewpoint?
> I'll give you both for the same price! Sysadmin viewpoint: to get
> a piece of software installed you need to install gettext/libintl,
> EVEN IF YOU DON'T FOR THE MOMENT CARE FOR ANYTHING ELSE THAN THE
> BUILTIN/DEFAULT (English) language. If you don't have it in
> your system, you will have the fun of trying to compile it.
> Developer viewpoint: I haven't tried this for years, but from what I
> have gathered it still sucks by being (a) much too simplistic for larger
> or more complicated projects (b) not understanding Unicode well. It was
> probably fine for small projects back in the 80s but something better is
> needed for today.
>
> > -spc (Perhaps a better question is---why do you *need* a 64-bit ethereal?)
>
> I am no Merijn but I guess the issue is that he has hardware and OS
> on it that simply is 64 bits, and he needs to compile from scratch
> because nobody else has done that for him.
Right. And that brings me back to why this started. The HP porting center
have ported all this shit only to 32bit builds, so if I want to install a
prebuilt ethereal binary, I also need to install all the deps first. Those
include libraries that are already installed as 64bit builds, as the target
system is supposed to be 64bit only. That means that those requirements will
overwrite the carefully built 64bit libraries with 32bit versions that I do
not want to use, but are only required for ethereal. So I do not really need
a 64bit ethereal, but I need ir because it depends on libraries that need to
be the same bitness. As 32bit and 64bit do not mix on HP-UX (and many other
OS's), I cannot use a 32bit ethereal, as I cannot have 32bit libs.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
There's stuff above here
Generated at 07:00 on 25 Apr 2006 by mariachi 0.52