[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dynamic object searching (was: Re: Dynamic objects)
From: |
Eli Zaretskii |
Subject: |
Re: dynamic object searching (was: Re: Dynamic objects) |
Date: |
Tue, 30 Apr 2013 20:07:15 +0300 |
> 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.
- Re: dynamic object searching (was: Re: Dynamic objects), (continued)
- Re: dynamic object searching (was: Re: Dynamic objects), David Boyce, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), Paul Smith, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), David Boyce, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), Edward Welbourne, 2013/04/29
- Re: dynamic object searching, Eli Zaretskii, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), Eli Zaretskii, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), Tim Murphy, 2013/04/30
- Re: dynamic object searching (was: Re: Dynamic objects), David Boyce, 2013/04/30
- Re: dynamic object searching (was: Re: Dynamic objects), Eli Zaretskii, 2013/04/30
- Re: dynamic object searching (was: Re: Dynamic objects), Tim Murphy, 2013/04/30
- Re: dynamic object searching (was: Re: Dynamic objects),
Eli Zaretskii <=
- Re: dynamic object searching (was: Re: Dynamic objects), Paul Smith, 2013/04/30
- Re: dynamic object searching (was: Re: Dynamic objects), Tim Murphy, 2013/04/30
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82), Paul Smith, 2013/04/29
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82), Tim Murphy, 2013/04/29
- memory allocation (was: Re: Dynamic objects), Paul Smith, 2013/04/29
- Re: memory allocation, Eli Zaretskii, 2013/04/29
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82), Eli Zaretskii, 2013/04/29
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82), Eli Zaretskii, 2013/04/29
Message not available