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 > Gentoo > Gentoo Embedded

 
 
LinkBack Thread Tools
 
Old 12-31-2010, 12:15 AM
Enrico Weigelt
 
Default configu error: C++ compiler cannot create executables

* Kfir Lavi <lavi.kfir@gmail.com> schrieb:

> > Patching autogenerated files is not a good idea - change the
> > actual source and regenerate.
> >
> In the ACE files they ask not to generate configure alone.

Well, not the first time I hear upstreams confusing intermediate
files w/ actual sources (yes, there're also folks who include
precompiled binaries, which are run and later recompiled within
the build process ;-o). A very good indicator for something
completely conceptionally wrong in here ;-p

My approach (which I'm doing in the OSS-QM project) is radically
clear: autogenerated files *must* be regenerated on each build.
If this doesn't work, the source is broken and has to be fixed,
period ;-p

I'm even going farer: if upstream has an proper vcs, I take the
releases from there, completely regenerating everything from
scratch. All fixes are done within my VCS (essentially, I always
have my own releases ontop the upstream's, as git tags). Sometimes
you encounter packages, eg. coreutils, which doing really messy
things like pulling in another tree via git and copying in files
from there - a nightmare for packagers ;-o

> So I tried it
> But had problem to finish.
> My guess they still tweak by hand.

WTF ? Tweak autoconf-generated files by hand ? Oh, I don't even
wanna know which drugs they're on ;-)


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
 
Old 12-31-2010, 04:07 PM
Kfir Lavi
 
Default configu error: C++ compiler cannot create executables

On Fri, Dec 31, 2010 at 3:15 AM, Enrico Weigelt <weigelt@metux.de> wrote:


* Kfir Lavi <lavi.kfir@gmail.com> schrieb:



> > Patching autogenerated files is not a good idea - change the

> > actual source and regenerate.

> >

> In the ACE files they ask not to generate configure alone.



Well, not the first time I hear upstreams confusing intermediate

files w/ actual sources (yes, there're also folks who include

precompiled binaries, which are run and later recompiled within

the build process ;-o). A very good indicator for something

completely conceptionally wrong in here ;-p



My approach (which I'm doing in the OSS-QM project) is radically

clear: autogenerated files *must* be regenerated on each build.

If this doesn't work, the source is broken and has to be fixed,

period ;-p


Well, you are a purist ;-)
The thing is, I must use this ACE libs, and they are broken.
I have also so many other things to get working, I just have to live with this approach.
Your method regenerating the ./configure script, is very good, and I'm asking myself, why


its not done every install, or why we get ./configure generated in the tar.gz.
Maybe there is something to it.
*



I'm even going farer: if upstream has an proper vcs, I take the

releases from there, completely regenerating everything from

scratch. All fixes are done within my VCS (essentially, I always

have my own releases ontop the upstream's, as git tags). Sometimes

you encounter packages, eg. coreutils, which doing really messy

things like pulling in another tree via git and copying in files

from there - a nightmare for packagers ;-o


I wonder, do you patch every ebuild to do just that?
Maybe there should be a new FEATURE that request the ebuild to download the release from the VCS.




> So I tried it

> But had problem to finish.

> My guess they still tweak by hand.



WTF ? Tweak autoconf-generated files by hand ? Oh, I don't even

wanna know which drugs they're on ;-)

*



cu

--

----------------------------------------------------------------------

*Enrico Weigelt, metux IT service -- http://www.metux.de/



*phone: *+49 36207 519931 *email: weigelt@metux.de

*mobile: +49 151 27565287 *icq: * 210169427 * * * * skype: nekrad666

----------------------------------------------------------------------

*Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme

----------------------------------------------------------------------
 
Old 01-02-2011, 09:38 PM
Enrico Weigelt
 
Default configu error: C++ compiler cannot create executables

* Kfir Lavi <lavi.kfir@gmail.com> schrieb:

> Well, you are a purist ;-)

At this point, yes ;-p

> The thing is, I must use this ACE libs, and they are broken.
> I have also so many other things to get working, I just have to live with
> this approach.

Yep, I know lots of those situations where you have to get the
job done, but stumble across dozens of problems which would
have been prevented by proper development methods and workflows.

Just experiencing that at my current customer, where they don't
even have a proper vcs (TFS is even more insane than SVN ;-o)

> Your method regenerating the ./configure script, is very good,

And often it's necessary, when you have the configure.in stuff.

> and I'm asking myself, why its not done every install, or why we
> get ./configure generated in the tar.gz.

These arguments I've heared over the years:

a) save time and cpu cycles for end users
b) get around autotools version conflicts
c) we always did so, so why change ?

I dont buy any of them. There're better solutions.

The best solution, IMHO, would be replacing all these dubious macros
by a bunch of carefully written shell functions. Something like

AC_CHECK_HEADER([foo.h],[do-something-if-found],[do-someting-if-not-found])

could be easily replaced by:

if ac_check_header foo.h ; then
do-something-if-found
else
do-something-if-not-found
fi

There would be no generation phase at all.


I've started some hacking on that for zlib, a while ago. Maybe
somebody might like to join me ...

> > I'm even going farer: if upstream has an proper vcs, I take the
> > releases from there, completely regenerating everything from
> > scratch. All fixes are done within my VCS (essentially, I always
> > have my own releases ontop the upstream's, as git tags). Sometimes
> > you encounter packages, eg. coreutils, which doing really messy
> > things like pulling in another tree via git and copying in files
> > from there - a nightmare for packagers ;-o
> >
> > I wonder, do you patch every ebuild to do just that?
>
> Maybe there should be a new FEATURE that request the ebuild to download the
> release from the VCS.

That probably multiplies the QM load to the ebuild maintainers,
as they would have to maintain different versions with the same
version number. And the benefit is questionable.

I'd rather propose (on per-package basis) directly maintain the sources
(including dist-specific changes) in an own repository, so the whole
download+unpack+patch phase is replaced by just a checkout, and things
like rebasing dist-specific changes can be done directly via vcs.

These repositories can now also be used easily by other folks,
distros can monitor and share their changes easily.

http://www.metux.de/download/oss-qm/normalized_repository.pdf


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
 
Old 02-05-2011, 02:16 PM
Enrico Weigelt
 
Default configu error: C++ compiler cannot create executables

* Peter Stuge <peter@stuge.se> schrieb:

> I think you're missing the point then. The point is obviously to
> allow source packages to compile on a very wide variety of platforms.
> Specifically, the auto* packages should not be needed on the build
> system. This is why configure is included in releases, and tries to
> run on as many different shells as possible.

Yes, but that whole idea introduces a hell more trouble than it's
ever worth it. Starting with the fact that they have to use a
very ancient shell language or even ugly hacks to work around
incompatibilities between ancient shells.

If we'd at least expect quite recent a shell that is capable of
handling functions, the whole machinery could be written entirely
in shellscripts - no macro-based generation at all. When appropriate,
there could be different, platform specific, version of these functions,
which are just included by the detected host and target type. A simple
configure script the probably would look like this:


#!/bin/sh

PACKAGE="mypackage"
VERSION="1.2.3"
AUTHOR="foo@bar.de"

. cf/autoconfig.sh

autoconfig_init

declare_feature "compression" "enable compression support using zlib"
declare_feature "png" "png image loading support"

autoconfig_begin

if `feature_enabled compression` ; then
require_header zlib.h
fi

if `feature_enabled png` ; then
require_package PNG "png >= 1.4.0"
fi

check_header malloc.h

generate_files
Makefile
src/Makefile
doc/Makefile

autoconfig_finish


Everything else could be easily hidden behind the shell functions.

> > The best solution, IMHO, would be replacing all these dubious
> > macros by a bunch of carefully written shell functions.
>
> Of course you already know that in fact the macros *are* shell
> functions. Look in a generated configure. They may be unrolled,
> but still.

No, they aren't. They are just macros which are expanded to a big-fat
unreable shellscript w/o any functions.

> > There would be no generation phase at all.
>
> Generation would be traded for a build-time requirement to have the
> library of shell functions installed on the system. Such a regression
> is not an option.

The shell functions could simply be included in the source tree
(eg. in some sane subdir). And the main script could even have some
switching mechanism, so an already installed version can be used
when requested.


AUTOCONFIG_LIBRARY=/usr/share/autoconfig-1.2 ./configure <....>


> > I've started some hacking on that for zlib, a while ago. Maybe
> > somebody might like to join me ...
>
> It would be interesting to see what you come up with there. IIRC zlib
> is not using full-on autotools though?

It's not using autotools at all - everything hand-written.

> Rewriting autoconf to use sh instead of m4 is an interesting idea. I
> think it would make sense to phase out m4. But I also don't think it
> is a strong requirement.

For me it often becomes requirement as during the last decade, it's
macros have turned out to be so broken and hard to debug.

> > I'd rather propose (on per-package basis) directly maintain the sources
> > (including dist-specific changes) in an own repository, so the whole
> > download+unpack+patch phase is replaced by just a checkout, and things
> > like rebasing dist-specific changes can be done directly via vcs.
>
> Except that it creates a proper fork of every package, which is
> pretty stupid IMO.

No, it's not a full fork, but just a downstream branch. Essentially the
same as done w/ text-based patches, just now stored directly in an
sophisticated vcs which supports the common operations like rebase.

> Yes this happens in practise with patches too, but
> in my view patches are really only temporary fixes until upstream has
> solved the problem better.

Same with an downstream-branch. Once upstream has taken a change, it
will automatically disappear from the downstream own changeset line
(which sits ontop the upstream) on next rebase. That's one of the
things rebase is good for.

> The purpose of a source-based distribution is to use the upstream
> sources. Some upstreams have significant QA which it would be silly
> to not take full advantage of, by using their released archive.

In the generic case, you don't use the upstream sources, but upstream
plus certain patches (or even worse: esoteric manipulations v/ sed, etc).
Only a subset (no matter which percentage it actually makes up) of the
package releases can be _directly_ pulled from upstream. The more
generic case is the superset of releases where a variable number
of changes (which *might* be zero) has to be added to the release.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
 
Old 02-06-2011, 06:21 AM
Mike Frysinger
 
Default configu error: C++ compiler cannot create executables

On Saturday, February 05, 2011 10:16:16 Enrico Weigelt wrote:
> No, they aren't. They are just macros which are expanded to a big-fat
> unreable shellscript w/o any functions.

once again you show that you dont follow the projects you spend time
criticizing. autoconf has for quite some time now required shells to support
functions since it generates code that uses functions.
-mike
 
Old 02-13-2011, 09:28 PM
Enrico Weigelt
 
Default configu error: C++ compiler cannot create executables

* Mike Frysinger <vapier@gentoo.org> schrieb:
> On Saturday, February 05, 2011 10:16:16 Enrico Weigelt wrote:
> > No, they aren't. They are just macros which are expanded to a big-fat
> > unreable shellscript w/o any functions.
>
> once again you show that you dont follow the projects you spend time
> criticizing. autoconf has for quite some time now required shells to support
> functions since it generates code that uses functions.

Well, actually, there are a few shell functions somewhere deep
in the fat shellscript, but still it's lightyears away from
the concept of structured programming w/ functions/procedures
(introduced somewhere in the 60th).

A about 130 lines configure.ac still produces a 13.800 lines
unreadable configure script (factor 100 !).

Why isn't, eg., something like AC_CHECK_LIB just a function call ?
There could be easily one generic function that does the job on
the given parameters and also tells the success as return value,
so you could directly write:

ac_check_library 'z' 'zlibVersion' || ac_error 'zlib not installed'

instead of:

AC_CHECK_LIB(z, zlibVersion, , AC_ERROR([zlib not installed]))
(which translates to more than 60 lines of shell code in the fat script).


BTW: the whole AC_CHECK_LIB approach (trying to compile a call to
the given function name) uses broken C code - try it on GCC with
-Werror and see what happens ;-o


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
 
Old 02-14-2011, 04:30 AM
Mike Frysinger
 
Default configu error: C++ compiler cannot create executables

On Sunday, February 13, 2011 17:28:19 Enrico Weigelt wrote:
> Why isn't, eg., something like AC_CHECK_LIB just a function call ?
> There could be easily one generic function that does the job on
> the given parameters and also tells the success as return value,
> so you could directly write:

you mean "why hasnt it been done yet?". i imagine they're focusing on the
lower pieces first before they start picking the higher fruit. obviously a
AC_CHECK_LIB is really just a special case for linking a C file against some
library. and autoconf already has turned the basic compile/link steps into
functions. i'd say the obvious answer is "help out", but not much point with
you.
-mike
 

Thread Tools




All times are GMT. The time now is 06:14 AM.

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