LD_PATHS

[Ralf Corsepius]

On Wed, 2005-04-20 at 01:55 -0700, Till Straumann wrote:
> Ralf Corsepius wrote:
> 
> >On Tue, 2005-04-19 at 20:28 -0700, Till Straumann wrote:
> >  
> >
> >>Ralf Corsepius wrote:
> >>
> >>    
> >>
> >>>On Tue, 2005-04-19 at 17:25 -0700, Till Straumann wrote:

> >Well you are just facing the symptoms of the makefile templates'
> >brokenness.
> >
> >Read what you wrote: "applications ... they rely ... don't break it"
> >
> >This is the trap the Makefile-templates are stuck in: They can't be
> >changed, not any feature can be removed from them, RTEMS would have to
> >stick with anything having ever been introduced somewhere, sometime.
> >
> >The only resolution to this dilemma from an RTEMS perspective I see, is
> >to officially announce them dead.
> >
> >Then _you_ would have to maintain these inside of your applications, or
> >you would have to implement an add-on package to RTEMS to cater your
> >applications.
> >
> Fine with me if the RTEMS/BSP specifica can be cleanly separated out. 
> The problem I had
> since the beginning (i.e., when I started doing RTEMS) was that I *had* 
> to use that makefile
> system in order to get the right specs, BSP build rules etc.
This should have improved now.

All you need to know is:
* The correct CFLAGS to pickup the correct multilib - This problem is a
not an RTEMS problem, it is a general one, you have on all OSes.

* The bsp_specs for your BSP and the directory it can be found.
-B<whereever>/ --spec <bspspec>

* The link/building bootimages rules (cf. below) and the MANAGERS magic.
These are still open problems.

> >However, there is one big difference between the current situation and
> >this situation: Unlike RTEMS, you know what your applications want and
> >have any freedom adapt it to your demands at any time.
> >
> Hmm - there are still two issues that come to my mind which are not 
> application dependent:
>  - how to pick compiler options, linker scripts etc.

Consider this: RTEMS is the OS, applications are using the OS.
=> Like on any other OS it should be your application's rsp. the "system
integrator's" task to choose appropriate compiler options.

>  I guess you say 
> 'spec file' and yet this
This would be one option.

>    has to picked up from somewhere.
Yes, e.g. where you tell your application to pick it up from.

Another option is using pkgconfig or you using appropriate autoconf
magic. 

>  - BSP specific rules to generate a bootable image
This is an open problem, having been on my agenda for years :(
Unfortunately there still are too many open issues (One roadbloack ist
the makefile templates; another one is lack of consistency in make
suffix rules being used in BSP.cfg) related to it to implement the
implementation I have in mind, nor did I find sufficient time to
implement it.

Short outline:
1. Split building bootimages into 2 steps:
a) link the application binary (eg. *.exe). 
b) convert the "binary" into a bootimage (eg. *.bin)
2. Implement the 2 steps from 1. into suffix rules in BSP.cfg.
3. Implement scripts using a unified command options for step 1.b). In
an ideal world, we would have a single unified tool for all targets/BSP.

Until now, I have several times tried to implement step 1. and 2., but
had given in frustrated, because people rejected it as "too massive" and
"breaks" existing applications :(

Therefore, you've got, what you've got ;)

> >ATM, I am considering to insist on them being removed for rtems-4.7.
> >
> How about deprecating and *freezing* them first?
>From my point of view they have been _dead_ and unmaintained since
4.6.0 :-)

> >>Call it a documentation bug
> >>but since that documentation bug has been out there for a long time it's 
> >>dangerous to assume that nobody uses the documented features...
> >>    
> >>
> >Ask Joel, he is the person in charge of the application makefile
> >fragments - I refuse to look into them.
> >  
> >
> You didn't refuse to make that change though ;-)

Note the date: 2002 - IIRC, at that time gcc-target-default.cfg had
still been used by the source tree.

I recall having removed many of the (now unused) variables having been
used by the Makefile fragments since them until I finally managed to not
use them at all, anymore - I also recall that pretty unpleasant
discussion on GNATS :)

Ralf