public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [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).