* [ECOS] Configtool libtarget.a build malfunction?
@ 2001-08-10 4:01 harri.siirtola
2001-08-10 5:04 ` Julian Smart
2001-08-10 5:17 ` Bart Veer
0 siblings, 2 replies; 4+ messages in thread
From: harri.siirtola @ 2001-08-10 4:01 UTC (permalink / raw)
To: ecos-discuss
It looks like the Configuration Tool 2.0 builds the library by replacing
lib members, not recreating the whole library. Example situation: I want to
remove POSIX pthread support and write my enhanced pthread_create() etc..
If I just uncheck POSIX thread support and rebuild, the pthread functions
remain in libtarget.a, resulting to redefinition error in my application
link phase. Is this intended for some obvious reason?
Now I must save to another xxx.ecc and build all.
Cheers,
Harri
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Configtool libtarget.a build malfunction?
2001-08-10 4:01 [ECOS] Configtool libtarget.a build malfunction? harri.siirtola
@ 2001-08-10 5:04 ` Julian Smart
2001-08-10 5:10 ` Andrew Lunn
2001-08-10 5:17 ` Bart Veer
1 sibling, 1 reply; 4+ messages in thread
From: Julian Smart @ 2001-08-10 5:04 UTC (permalink / raw)
To: harri.siirtola, ecos-discuss
At 01:57 PM 8/10/01 +0300, harri.siirtola@vtt.fi wrote:
>It looks like the Configuration Tool 2.0 builds the library by replacing
>lib members, not recreating the whole library. Example situation: I want to
>remove POSIX pthread support and write my enhanced pthread_create() etc..
>If I just uncheck POSIX thread support and rebuild, the pthread functions
>remain in libtarget.a, resulting to redefinition error in my application
>link phase. Is this intended for some obvious reason?
To be honest the makefiles are something of a mystery to me still. Hmm,
maybe the Configtool needs to issue a clean before the build...
Julian
--
Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1
7EG Tel: +44 (1223) 271063
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Configtool libtarget.a build malfunction?
2001-08-10 5:04 ` Julian Smart
@ 2001-08-10 5:10 ` Andrew Lunn
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Lunn @ 2001-08-10 5:10 UTC (permalink / raw)
To: Julian Smart; +Cc: harri.siirtola, ecos-discuss
On Fri, Aug 10, 2001 at 01:09:24PM +0100, Julian Smart wrote:
> At 01:57 PM 8/10/01 +0300, harri.siirtola@vtt.fi wrote:
>
> >It looks like the Configuration Tool 2.0 builds the library by replacing
> >lib members, not recreating the whole library. Example situation: I want to
> >remove POSIX pthread support and write my enhanced pthread_create() etc..
> >If I just uncheck POSIX thread support and rebuild, the pthread functions
> >remain in libtarget.a, resulting to redefinition error in my application
> >link phase. Is this intended for some obvious reason?
>
> To be honest the makefiles are something of a mystery to me still. Hmm,
> maybe the Configtool needs to issue a clean before the build...
All it realy needs to do is remove the install/lib directory.
I think the clean target also removes any source code you may have in
the work tree. I found this out the hard way :-(
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Configtool libtarget.a build malfunction?
2001-08-10 4:01 [ECOS] Configtool libtarget.a build malfunction? harri.siirtola
2001-08-10 5:04 ` Julian Smart
@ 2001-08-10 5:17 ` Bart Veer
1 sibling, 0 replies; 4+ messages in thread
From: Bart Veer @ 2001-08-10 5:17 UTC (permalink / raw)
To: harri.siirtola; +Cc: ecos-discuss
>>>>> "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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-08-10 5:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-10 4:01 [ECOS] Configtool libtarget.a build malfunction? harri.siirtola
2001-08-10 5:04 ` Julian Smart
2001-08-10 5:10 ` Andrew Lunn
2001-08-10 5:17 ` Bart Veer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).