Re: dynamic object searching (was: Re: Dynamic objects)

[Eli Zaretskii]

> Date: Tue, 30 Apr 2013 17:48:42 +0100
> From: Tim Murphy <address@hidden>
> Cc: "Paul D. Smith" <address@hidden>, "address@hidden" <address@hidden>
> 
> > That's unrelated.  I was talking about the fact that
> >
> >       load foo.so
> >
> > is inherently non-portable, whereas
> >
> >       load foo
> > or
> >       load foo$(SOEXT)
> >
> > (with $(SOEXT) determined automatically by Make) is much more
> > portable.
> 
> Everything's non-portable - trying to solve this doesn't help at all - just
> complicates the rest of the process.

I disagree.

> I have to generate those plugins anyhow so there's all the non-portable
> code to call whatever compiler and linker are needed for that particular
> platform.  All of that code has to specify the extension anyhow so what do
> I gain?
> 
> 
> i.e. I don't just have
> load X.dll
> 
> I have to supply the recipe to build it on windows:
> 
> X.dll:
>   cl.exe  /Fdo$@  .... # use microsoft's compiler

Not relevant: people who use GNU Make are unlikely to use cl, which
comes with Nmake.

I'm talking about building GNU projects using GNU Make and MinGW GCC.

Every problem can be turned upside down or made overly complicated by
throwing enough corner cases on it.  Let's solve the 80% part and
leave the other 20% to Someone Else.

> and on Linux
> X.so:
>    gcc -o $@  ... # using gcc

That's exactly what I do on Windows as well.

> On top of this, the extension doesn't help when you're on 32-bit platforms
> because it doesn't indicate whether the plugin is 32 or 64 bit.

Neither does GCC.  That's unrelated.

> So to me it just seems like a complication because it can't solve the whole
> problem that make generally needs explicit effort to support builds on
> multiple platforms.

You can always refrain from using it.