Sorry, for entering the discussion at this late stage. After reading
all the follow-ups to Jonas message below, I understood that the
culprit is still link ordering. If I understood something wrong, then
please excuse my ignorance.
If not, It might help to add a link parameter (-k...) into the
On Mon, 06 Sep 2004 15:06:30 +0200, Eduardo Morras wrote
> At 11:19 06/09/2004, you wrote:
>
> >On 6 sep 2004, at 09:28, Marco van de Voort wrote:
> >
> >>>Especially in case the linker supports multiple namespaces and
> >>>one package needs symbol X from library A, and another one from library
>
04-09-06 15.06, skrev Eduardo Morras följande:
> At 11:19 06/09/2004, you wrote:
>
>> On 6 sep 2004, at 09:28, Marco van de Voort wrote:
>>
Especially in case the linker supports multiple namespaces and
one package needs symbol X from library A, and another one from library
B.
>>>
On Mon, 6 Sep 2004, Eduardo Morras wrote:
> At 11:19 06/09/2004, you wrote:
>
> >On 6 sep 2004, at 09:28, Marco van de Voort wrote:
> >
> >>>Especially in case the linker supports multiple namespaces and
> >>>one package needs symbol X from library A, and another one from library
> >>>B.
> >>
>
On 6 sep 2004, at 15:06, Eduardo Morras wrote:
No, it's not per system, but per package/program. Suppose there are
libraries A and B which both export symbol X. One program needs
symbol X from library A, and another one from library B, but both
need both libraries A and B for other symbols.
You
At 11:19 06/09/2004, you wrote:
On 6 sep 2004, at 09:28, Marco van de Voort wrote:
Especially in case the linker supports multiple namespaces and
one package needs symbol X from library A, and another one from library
B.
There is always some directed graph in dependancies that can be translated
int
On 6 sep 2004, at 09:28, Marco van de Voort wrote:
Especially in case the linker supports multiple namespaces and
one package needs symbol X from library A, and another one from
library
B.
There is always some directed graph in dependancies that can be
translated
into weights. But true, this kind
04-09-05 20.31, skrev Jonas Maebe följande:
>
> I simply meant that our compiler does part of what make normally does
> (figuring out dependencies, compiling different files, ...), but it's
> not a full-fledged make replacement. And some kinds of things are
> easier to handle with make (you don't
> On 5 sep 2004, at 20:17, Marco van de Voort wrote:
> >
> > This is no solution. I can use that, you can use that, 99% of our users
> > can't.
>
> I was not thinking of requiring the users to write makefiles (I agree
> we simply cannot do that). More that we call this stuff in the
> makefile,
