On 30 April 2013 17:28, Eli Zaretskii <e...@gnu.org> wrote: > > > Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit > > program, the real issue is what architecture was make itself built with. > > 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 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 and on Linux X.so: gcc -o $@ ... # using gcc 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. 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. Regards, Tim -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
