Re: dynamic object searching (was: Re: Dynamic objects)
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. It's sort of a matter of make identifying itself rather than telling you that you're running on ubuntu 13.04 or solaris 10. Regards, Tim On 30 April 2013 03:38, Eli Zaretskii e...@gnu.org wrote: From: Paul Smith psm...@gnu.org Cc: Tim Murphy tnmur...@gmail.com, bug-make@gnu.org Date: Mon, 29 Apr 2013 16:34:01 -0400 On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote: Yes, that should be possible. My concern is that, at least on UNIX, the rules for this are complex and I don't want to reimplement the runtime linker :-). Maybe something like, first try the path as given and if that fails, try adding arch-specific extensions? No, much simpler: _always_ append _a_single_ arch-specific extension, and try loading that. We should document that extension; using the one that is used by default by the compiler for producing shared libraries should be good enough, I think. It's not so simple, though, as just .so vs. .dll. MacOS for example uses .dylib. And I think AIX does something else weird that I've forgotten about. Others probably do as well. Plus on UNIX any extension is acceptable since we're using dlopen() (even with the normal linker you can give any library name you want, it's only the -l flag that makes assumptions). Maybe someone wants to write pattern rules to build their GNU make loadable objects with a suffix .gmkso to distinguish it (and use a different rule) from building normal .so shared objects. I want to be sure the benefits outweight the loss of flexibility before we go down that path. OK, how about a lesser solution: have a builtin variable, say $SOEXT, which will have a platform-specific default extension of shared objects? Then whoever wants to use it for a portable Makefile, could do that, and people who want to use .gmkso can do that, too. WDYT? It's probably a good idea to have make predefine a variable containing the host architecture, to avoid the need for uname. That's a good feature regardless, but I think we should provide some solution for the extension as well. -- 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
Re: dynamic object searching (was: Re: Dynamic objects)
On Tue, Apr 30, 2013 at 3:57 AM, Tim Murphy tnmur...@gmail.com 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. It's sort of a matter of make identifying itself rather than telling you that you're running on ubuntu 13.04 or solaris 10. Which is exactly what make_host tells you. It provides the architecture make was built for in the form of e.g. x86_64-unknown-linux-gnu or whatever configure comes up with. On Mon, Apr 29, 2013 at 8:03 PM, David Boyce david.s.bo...@gmail.com wrote: On Mon, Apr 29, 2013 at 7:53 PM, Paul Smith psm...@gnu.org wrote: Well, David, when you suggested it I wasn't so sure. But now that I've thought of it myself... brilliant!! :-p :-) But now I'm having second thoughts ... That was, I hope it's clear, a feeble joke. I find Paul's insight to be a stroke of pure genius. -David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
Date: Tue, 30 Apr 2013 08:57:23 +0100 From: Tim Murphy tnmur...@gmail.com Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org 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. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
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
Re: dynamic object searching (was: Re: Dynamic objects)
Date: Tue, 30 Apr 2013 17:48:42 +0100 From: Tim Murphy tnmur...@gmail.com Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org 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. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
On Tue, 2013-04-30 at 17:48 +0100, Tim Murphy wrote: 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 Actually this supports Eli's point perfectly. This is no problem. You can just put both of those rules into your makefile, and if make defines an extension EXT for the current platform you can use load X.$(EXT) and when you're on Windows it will build one way and when you're on Linux it will build the other way. However, I'm still undecided on how to handle this. I'll look at it again shortly. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
That stuff about only using gnu tools is far from the case. Re this usecase supporting multiple platforms. The reason why it doesn't help is that all the rest of your makefile has similar multiplatform problems which you have to address with ifeq and its friends and it is nastier if you have make second guessing your decisions. Regards, Tim On 30/04/2013, Paul Smith psm...@gnu.org wrote: On Tue, 2013-04-30 at 17:48 +0100, Tim Murphy wrote: 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 Actually this supports Eli's point perfectly. This is no problem. You can just put both of those rules into your makefile, and if make defines an extension EXT for the current platform you can use load X.$(EXT) and when you're on Windows it will build one way and when you're on Linux it will build the other way. However, I'm still undecided on how to handle this. I'll look at it again shortly. -- 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
dynamic object searching (was: Re: Dynamic objects)
On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote: Yes, that should be possible. My concern is that, at least on UNIX, the rules for this are complex and I don't want to reimplement the runtime linker :-). Maybe something like, first try the path as given and if that fails, try adding arch-specific extensions? No, much simpler: _always_ append _a_single_ arch-specific extension, and try loading that. We should document that extension; using the one that is used by default by the compiler for producing shared libraries should be good enough, I think. It's not so simple, though, as just .so vs. .dll. MacOS for example uses .dylib. And I think AIX does something else weird that I've forgotten about. Others probably do as well. Plus on UNIX any extension is acceptable since we're using dlopen() (even with the normal linker you can give any library name you want, it's only the -l flag that makes assumptions). Maybe someone wants to write pattern rules to build their GNU make loadable objects with a suffix .gmkso to distinguish it (and use a different rule) from building normal .so shared objects. I want to be sure the benefits outweight the loss of flexibility before we go down that path. On Mon, 2013-04-29 at 23:13 +0300, Eli Zaretskii wrote: the same way one creates 1 makefile that can build the same code for 2 operating systems - something done every day. You make it up. You run uname with $(shell) or you pass in an argument from a top level script that does know the platform or whatever. In the end you have a bit of makefile that says: First, there's no uname on Windows. You are in fact saying that in order to run a Makefile one would need something similar to autoconf. It's probably a good idea to have make predefine a variable containing the host architecture, to avoid the need for uname. We currently have an internal variable make_host which is the GNU autoconf --host value on systems where configure runs, and the various config.h templates have hardcoded values. Maybe we could do something with this (just using the --host value might be too arbitrary, I'd have to look at the options). Which is kind of beside the point, but just a thought :-). ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith psm...@gnu.org wrote: Plus on UNIX any extension is acceptable since we're using dlopen() (even with the normal linker you can give any library name you want, it's only the -l flag that makes assumptions). Maybe someone wants to write pattern rules to build their GNU make loadable objects with a suffix .gmkso to distinguish it (and use a different rule) from building normal .so shared objects. I want to be sure the benefits outweight the loss of flexibility before we go down that path. Why not try opening the pathname as given, and if that fails append the platform-standard extension and try again? It's probably a good idea to have make predefine a variable containing the host architecture, to avoid the need for uname. We currently have an internal variable make_host which is the GNU autoconf --host value on systems where configure runs, and the various config.h templates have hardcoded values. Maybe we could do something with this (just using the --host value might be too arbitrary, I'd have to look at the options). I've twice submitted a patch to provide make_host as a make variable, but they've gone into the ether. It's a one-line patch and hugely useful IMHO considering the number of people who've had to reinvent the $(if $(shell uname)) etc wheel. It's impossible to determine how a given user or community will define platform, so no variable will work for everybody, but I think make_host is pretty hard to improve upon. -David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
On Mon, 2013-04-29 at 17:00 -0400, David Boyce wrote: On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith psm...@gnu.org wrote: Plus on UNIX any extension is acceptable since we're using dlopen() (even with the normal linker you can give any library name you want, it's only the -l flag that makes assumptions). Maybe someone wants to write pattern rules to build their GNU make loadable objects with a suffix .gmkso to distinguish it (and use a different rule) from building normal .so shared objects. I want to be sure the benefits outweight the loss of flexibility before we go down that path. Why not try opening the pathname as given, and if that fails append the platform-standard extension and try again? The issue is that we rebuild loaded objects if they are out of date. That means we need to do the whole try to remake thing. That gets more complex if there are multiple possible names for the loaded object. We can do the search and if we find one then it's easy: we just try to rebuild it. But if we don't find one, how do we choose what to build? We could use the same algorithm and try to build each one in turn (although that would be a pretty big change to the code; we don't really have a way to say build A or B or C... stop after the first one that succeeds or fail if none do). Although starting with an unadorned file like foo is not going to work so well since it will match lots of try-anything rules. It's just not pretty. It's probably a good idea to have make predefine a variable containing the host architecture, to avoid the need for uname. We currently have an internal variable make_host which is the GNU autoconf --host value on systems where configure runs, and the various config.h templates have hardcoded values. Maybe we could do something with this (just using the --host value might be too arbitrary, I'd have to look at the options). I've twice submitted a patch to provide make_host as a make variable, but they've gone into the ether. It's a one-line patch and hugely useful IMHO considering the number of people who've had to reinvent the $(if $(shell uname)) etc wheel. It's impossible to determine how a given user or community will define platform, so no variable will work for everybody, but I think make_host is pretty hard to improve upon. Well, David, when you suggested it I wasn't so sure. But now that I've thought of it myself... brilliant!! :-p :-) I'm not saying make_host is wrong. I do wish there was something more generic available (maybe in addition) that let people know posix vs windows vs. vms vs. amiga vs. whatever, and avoid a lot of makefiles with if linux or freebsd or openbsd or aix or hpux or But I guess you get into sticky areas: is MacOS posix even though it has so many differences from stock BSD? Are windows and msdos the same? What about msys vs. cygwin etc.? From the standpoint of writing a makefile I guess what you really want to know is, does this environment have a POSIX shell environment, or Windows command.com, or VMS shell (whatever that is)? Or something else (I'm not so familiar with all the variations on the Windows side) ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
On Mon, Apr 29, 2013 at 7:53 PM, Paul Smith psm...@gnu.org wrote: Well, David, when you suggested it I wasn't so sure. But now that I've thought of it myself... brilliant!! :-p :-) But now I'm having second thoughts ... -David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
... or VMS shell (whatever that is) ... it was called DCL (Digital Command Language, I suspect) and the one feature I remember clearly is its help. If you typed help at the prompt, it was actually *helpful* in response. I have not seen that since. Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
From: Paul Smith psm...@gnu.org Cc: Tim Murphy tnmur...@gmail.com, bug-make@gnu.org Date: Mon, 29 Apr 2013 16:34:01 -0400 On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote: Yes, that should be possible. My concern is that, at least on UNIX, the rules for this are complex and I don't want to reimplement the runtime linker :-). Maybe something like, first try the path as given and if that fails, try adding arch-specific extensions? No, much simpler: _always_ append _a_single_ arch-specific extension, and try loading that. We should document that extension; using the one that is used by default by the compiler for producing shared libraries should be good enough, I think. It's not so simple, though, as just .so vs. .dll. MacOS for example uses .dylib. And I think AIX does something else weird that I've forgotten about. Others probably do as well. Plus on UNIX any extension is acceptable since we're using dlopen() (even with the normal linker you can give any library name you want, it's only the -l flag that makes assumptions). Maybe someone wants to write pattern rules to build their GNU make loadable objects with a suffix .gmkso to distinguish it (and use a different rule) from building normal .so shared objects. I want to be sure the benefits outweight the loss of flexibility before we go down that path. OK, how about a lesser solution: have a builtin variable, say $SOEXT, which will have a platform-specific default extension of shared objects? Then whoever wants to use it for a portable Makefile, could do that, and people who want to use .gmkso can do that, too. WDYT? It's probably a good idea to have make predefine a variable containing the host architecture, to avoid the need for uname. That's a good feature regardless, but I think we should provide some solution for the extension as well. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
