[gentoo-embedded] configure: error: C++ compiler cannot create executables

[gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

Hi,
I have a cross compilation environment inside a chroot.
I run:
i686-unknown-linux-gnu-emerge dev-libs/ace
...
checking for i686-unknown-linux-gnu-g++... i686-unknown-linux-gnu-g++
checking for C++ compiler default output file name... configure:
error: C++ compiler cannot create executables

It seems to me that my toolchain is not complete and the C++ compiler
was not created correctly.

How can I solve this problem?

Regards,
Kfir

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Manuel Lauss]

On Sun, Oct 31, 2010 at 9:08 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
> Hi,
> I have a cross compilation environment inside a chroot.
> I run:
> i686-unknown-linux-gnu-emerge dev-libs/ace
> ...
> checking for i686-unknown-linux-gnu-g++... i686-unknown-linux-gnu-g++
> checking for C++ compiler default output file name... configure:
> error: C++ compiler cannot create executables

Have a look at config.log.  It tells exactly what went wrong, including gcc
error output.

Manuel

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

On Tue, Nov 2, 2010 at 2:49 PM, Manuel Lauss <manuel.lauss@googlemail.com>wrote:

> On Sun, Oct 31, 2010 at 9:08 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
> > Hi,
> > I have a cross compilation environment inside a chroot.
> > I run:
> > i686-unknown-linux-gnu-emerge dev-libs/ace
> > ...
> > checking for i686-unknown-linux-gnu-g++... i686-unknown-linux-gnu-g++
> > checking for C++ compiler default output file name... configure:
> > error: C++ compiler cannot create executables
>
> Have a look at config.log.  It tells exactly what went wrong, including gcc
> error output.
>
> Manuel
>
> It seems that one of the steps that I do, is deleting the tools. I need
then to install again from package from the mother system (I'm running here
as chroot, and its very good that I did so).
So I install gcc and binutils, then compile them again in the chroot
environment.
Using i686-unknown-linux-gnu-emerge and everything happens again.
I didn't find the culprit yet.

Kfir

[-- Attachment #2: Type: text/html, Size: 1459 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

On Wed, Nov 3, 2010 at 12:33 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

>
>
> On Tue, Nov 2, 2010 at 2:49 PM, Manuel Lauss <manuel.lauss@googlemail.com>wrote:
>
>> On Sun, Oct 31, 2010 at 9:08 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>> > Hi,
>> > I have a cross compilation environment inside a chroot.
>> > I run:
>> > i686-unknown-linux-gnu-emerge dev-libs/ace
>> > ...
>> > checking for i686-unknown-linux-gnu-g++... i686-unknown-linux-gnu-g++
>> > checking for C++ compiler default output file name... configure:
>> > error: C++ compiler cannot create executables
>>
>> Have a look at config.log.  It tells exactly what went wrong, including
>> gcc
>> error output.
>>
>> Manuel
>>
>> It seems that one of the steps that I do, is deleting the tools. I need
> then to install again from package from the mother system (I'm running here
> as chroot, and its very good that I did so).
> So I install gcc and binutils, then compile them again in the chroot
> environment.
> Using i686-unknown-linux-gnu-emerge and everything happens again.
> I didn't find the culprit yet.
>
> Kfir
>

It seems that installing dev-libs/ace is causing the problem.
emerge dev-libs/ace [works]
i686-gentoo-linux-gnu-g++ [works]
i686-gentoo-linux-gnu-gcc [works]
gcc [works]
g++ [works]
i686-gentoo-linux-gnu-emerge  dev-libs/ace [DONT WORK]

Other packages emerging ok with i686-gentoo-linux-gnu-emerge.
Can someone give me a hint? or something to check?

Thanks,
Kfir

[-- Attachment #2: Type: text/html, Size: 2301 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

On Wed, Nov 3, 2010 at 7:50 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

>
>
> On Wed, Nov 3, 2010 at 12:33 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>
>>
>>
>> On Tue, Nov 2, 2010 at 2:49 PM, Manuel Lauss <manuel.lauss@googlemail.com
>> > wrote:
>>
>>> On Sun, Oct 31, 2010 at 9:08 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>>> > Hi,
>>> > I have a cross compilation environment inside a chroot.
>>> > I run:
>>> > i686-unknown-linux-gnu-emerge dev-libs/ace
>>> > ...
>>> > checking for i686-unknown-linux-gnu-g++... i686-unknown-linux-gnu-g++
>>> > checking for C++ compiler default output file name... configure:
>>> > error: C++ compiler cannot create executables
>>>
>>> Have a look at config.log.  It tells exactly what went wrong, including
>>> gcc
>>> error output.
>>>
>>> Manuel
>>>
>>> It seems that one of the steps that I do, is deleting the tools. I need
>> then to install again from package from the mother system (I'm running here
>> as chroot, and its very good that I did so).
>> So I install gcc and binutils, then compile them again in the chroot
>> environment.
>> Using i686-unknown-linux-gnu-emerge and everything happens again.
>> I didn't find the culprit yet.
>>
>> Kfir
>>
>
> It seems that installing dev-libs/ace is causing the problem.
> emerge dev-libs/ace [works]
> i686-gentoo-linux-gnu-g++ [works]
> i686-gentoo-linux-gnu-gcc [works]
> gcc [works]
> g++ [works]
> i686-gentoo-linux-gnu-emerge  dev-libs/ace [DONT WORK]
>
> Other packages emerging ok with i686-gentoo-linux-gnu-emerge.
> Can someone give me a hint? or something to check?
>
> Thanks,
> Kfir
>

Some diagnostics:
$ cd /usr/__CHOST__/tmp/portage/dev-libs/ace-5.7.2/work/ACE_wrappers/build
$ ../configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for egrep... grep -E
checking whether #! works in shell scripts... yes
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E

Here we see that configure passes the test it failed with emerge.
One line did grab my attention: checking whether we are cross compiling...
no

Maybe the environment that i686-gentoo-linux-gnu-emerge creates is not
working for ACE.

What do you think?

Regards,
Kfir

[-- Attachment #2: Type: text/html, Size: 4103 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 3515 bytes --]

On Wed, Nov 3, 2010 at 8:32 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

>
>
> On Wed, Nov 3, 2010 at 7:50 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>
>>
>>
>> On Wed, Nov 3, 2010 at 12:33 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Nov 2, 2010 at 2:49 PM, Manuel Lauss <
>>> manuel.lauss@googlemail.com> wrote:
>>>
>>>> On Sun, Oct 31, 2010 at 9:08 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>>>> > Hi,
>>>> > I have a cross compilation environment inside a chroot.
>>>> > I run:
>>>> > i686-unknown-linux-gnu-emerge dev-libs/ace
>>>> > ...
>>>> > checking for i686-unknown-linux-gnu-g++... i686-unknown-linux-gnu-g++
>>>> > checking for C++ compiler default output file name... configure:
>>>> > error: C++ compiler cannot create executables
>>>>
>>>> Have a look at config.log.  It tells exactly what went wrong, including
>>>> gcc
>>>> error output.
>>>>
>>>> Manuel
>>>>
>>>> It seems that one of the steps that I do, is deleting the tools. I need
>>> then to install again from package from the mother system (I'm running here
>>> as chroot, and its very good that I did so).
>>> So I install gcc and binutils, then compile them again in the chroot
>>> environment.
>>> Using i686-unknown-linux-gnu-emerge and everything happens again.
>>> I didn't find the culprit yet.
>>>
>>> Kfir
>>>
>>
>> It seems that installing dev-libs/ace is causing the problem.
>> emerge dev-libs/ace [works]
>> i686-gentoo-linux-gnu-g++ [works]
>> i686-gentoo-linux-gnu-gcc [works]
>> gcc [works]
>> g++ [works]
>> i686-gentoo-linux-gnu-emerge  dev-libs/ace [DONT WORK]
>>
>> Other packages emerging ok with i686-gentoo-linux-gnu-emerge.
>> Can someone give me a hint? or something to check?
>>
>> Thanks,
>> Kfir
>>
>
> Some diagnostics:
> $ cd /usr/__CHOST__/tmp/portage/dev-libs/ace-5.7.2/work/ACE_wrappers/build
> $ ../configure
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for egrep... grep -E
> checking whether #! works in shell scripts... yes
> checking for g++... g++
> checking for C++ compiler default output file name... a.out
> checking whether the C++ compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking for style of include used by make... GNU
> checking dependency style of g++... gcc3
> checking how to run the C++ preprocessor... g++ -E
>
> Here we see that configure passes the test it failed with emerge.
> One line did grab my attention: checking whether we are cross compiling...
> no
>
> Maybe the environment that i686-gentoo-linux-gnu-emerge creates is not
> working for ACE.
>
> What do you think?
>
> Regards,
> Kfir
>

I did again a cross compilation, really the same way I did before, but with
a different name.
crossdev -P -vt i686-gentoo1-linux-gnu
But without the -S, so it compiled all the latest and greatest.

Now the problem is solved, but still ACE will stuck on another line:
checking for epoll_create... configure: error: cannot run test program while
cross compiling
See `config.log' for more details.

But this is for different thread.

Regards,
Kfir

[-- Attachment #2: Type: text/html, Size: 5021 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Enrico Weigelt]

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

> Now the problem is solved, but still ACE will stuck on another line:
> checking for epoll_create... configure: error: cannot run test program while
> cross compiling

They're using AC_TRY_RUN(), which is completely ridiculus.

File an upstream report. 


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

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

On Mon, Nov 8, 2010 at 12:04 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

>
>
> On Wed, Nov 3, 2010 at 8:32 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>
>>
>>
>> On Wed, Nov 3, 2010 at 7:50 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Nov 3, 2010 at 12:33 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Nov 2, 2010 at 2:49 PM, Manuel Lauss <
>>>> manuel.lauss@googlemail.com> wrote:
>>>>
>>>>> On Sun, Oct 31, 2010 at 9:08 AM, Kfir Lavi <lavi.kfir@gmail.com>
>>>>> wrote:
>>>>> > Hi,
>>>>> > I have a cross compilation environment inside a chroot.
>>>>> > I run:
>>>>> > i686-unknown-linux-gnu-emerge dev-libs/ace
>>>>> > ...
>>>>> > checking for i686-unknown-linux-gnu-g++... i686-unknown-linux-gnu-g++
>>>>> > checking for C++ compiler default output file name... configure:
>>>>> > error: C++ compiler cannot create executables
>>>>>
>>>>> Have a look at config.log.  It tells exactly what went wrong, including
>>>>> gcc
>>>>> error output.
>>>>>
>>>>> Manuel
>>>>>
>>>>> It seems that one of the steps that I do, is deleting the tools. I need
>>>> then to install again from package from the mother system (I'm running here
>>>> as chroot, and its very good that I did so).
>>>> So I install gcc and binutils, then compile them again in the chroot
>>>> environment.
>>>> Using i686-unknown-linux-gnu-emerge and everything happens again.
>>>> I didn't find the culprit yet.
>>>>
>>>> Kfir
>>>>
>>>
>>> It seems that installing dev-libs/ace is causing the problem.
>>> emerge dev-libs/ace [works]
>>> i686-gentoo-linux-gnu-g++ [works]
>>> i686-gentoo-linux-gnu-gcc [works]
>>> gcc [works]
>>> g++ [works]
>>> i686-gentoo-linux-gnu-emerge  dev-libs/ace [DONT WORK]
>>>
>>> Other packages emerging ok with i686-gentoo-linux-gnu-emerge.
>>> Can someone give me a hint? or something to check?
>>>
>>> Thanks,
>>> Kfir
>>>
>>
>> Some diagnostics:
>> $ cd /usr/__CHOST__/tmp/portage/dev-libs/ace-5.7.2/work/ACE_wrappers/build
>> $ ../configure
>> checking build system type... i686-pc-linux-gnu
>> checking host system type... i686-pc-linux-gnu
>> checking target system type... i686-pc-linux-gnu
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking for egrep... grep -E
>> checking whether #! works in shell scripts... yes
>> checking for g++... g++
>> checking for C++ compiler default output file name... a.out
>> checking whether the C++ compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables...
>> checking for suffix of object files... o
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether g++ accepts -g... yes
>> checking for style of include used by make... GNU
>> checking dependency style of g++... gcc3
>> checking how to run the C++ preprocessor... g++ -E
>>
>> Here we see that configure passes the test it failed with emerge.
>> One line did grab my attention: checking whether we are cross compiling...
>> no
>>
>> Maybe the environment that i686-gentoo-linux-gnu-emerge creates is not
>> working for ACE.
>>
>> What do you think?
>>
>> Regards,
>> Kfir
>>
>
> I did again a cross compilation, really the same way I did before, but with
> a different name.
> crossdev -P -vt i686-gentoo1-linux-gnu
> But without the -S, so it compiled all the latest and greatest.
>
> Now the problem is solved, but still ACE will stuck on another line:
> checking for epoll_create... configure: error: cannot run test program
> while cross compiling
> See `config.log' for more details.
>
> But this is for different thread.
>
> Regards,
> Kfir
>
I have created an ebuild that deletes the epoll test from configure.
I have posted it here: http://bugs.gentoo.org/show_bug.cgi?id=348521
After eliminating the epoll test, the compilation passes.

Regards,
Kfir

[-- Attachment #2: Type: text/html, Size: 5744 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Enrico Weigelt]

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

> I have created an ebuild that deletes the epoll test from configure.
> I have posted it here: http://bugs.gentoo.org/show_bug.cgi?id=348521
> After eliminating the epoll test, the compilation passes.

Patching autogenerated files is not a good idea - change the
actual source and regenerate.


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

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Thu, Dec 30, 2010 at 8:27 AM, Enrico Weigelt <weigelt@metux.de> wrote:

> * Kfir Lavi <lavi.kfir@gmail.com> schrieb:
>
> > I have created an ebuild that deletes the epoll test from configure.
> > I have posted it here: http://bugs.gentoo.org/show_bug.cgi?id=348521
> > After eliminating the epoll test, the compilation passes.
>
> 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. So I tried it ;)
But had problem to finish.
My guess they still tweak by hand.
This is why I went to the auto-generated file. Not the best, but solves the
problem for now.

Kfir

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

[-- Attachment #2: Type: text/html, Size: 2011 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Enrico Weigelt]

* 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
----------------------------------------------------------------------

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3768 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Enrico Weigelt]

* 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
----------------------------------------------------------------------

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Peter Stuge]

Enrico Weigelt wrote:
> > 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 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.


> 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.


> 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.


> 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?

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.


> 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. 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. 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.


//Peter

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Enrico Weigelt]

* 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
----------------------------------------------------------------------

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 395 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Enrico Weigelt]

* 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
----------------------------------------------------------------------

Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 705 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]