This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Configtool libtarget.a build malfunction?
- To: harri dot siirtola at vtt dot fi
- Subject: Re: [ECOS] Configtool libtarget.a build malfunction?
- From: Bart Veer <bartv at redhat dot com>
- Date: Fri, 10 Aug 2001 13:16:57 +0100
- Cc: ecos-discuss at sources dot redhat dot com
- References: <3.0.32.20010810135749.009b1920@vttmail.vtt.fi>
- Reply-To: bartv at redhat dot com
>>>>> "harri" == harri siirtola <harri.siirtola@vtt.fi> writes:
harri> It looks like the Configuration Tool 2.0 builds the library
harri> by replacing lib members, not recreating the whole library.
harri> Example situation: I want to remove POSIX pthread support
harri> and write my enhanced pthread_create() etc.. If I just
harri> uncheck POSIX thread support and rebuild, the pthread
harri> functions remain in libtarget.a, resulting to redefinition
harri> error in my application link phase. Is this intended for
harri> some obvious reason?
There are a number of problems with the current makefile generation
code, and unfortunately they do not have easy solutions. One
fundamental problem is that the system does not preserve enough
readily-accessible state to know what files were appropriate to build
for the previous configuration, so that it can figure out what has
actually changed.
The whole makefile generation system needs a major overhaul.
harri> Now I must save to another xxx.ecc and build all.
That is the safest course of action for now, regrettably.
>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:
Andrew> All it realy needs to do is remove the install/lib
Andrew> directory.
Nope, that does not work AFAIK. Generating the libraries happens via
side effects, rather than explicit dependencies between archive
members and object files.
Andrew> I think the clean target also removes any source code you
Andrew> may have in the work tree. I found this out the hard way
Andrew> :-(
Yes, another of the known problems.
Bart