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
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
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.
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
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
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
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
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
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
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
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
... 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.
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
13 matches
Mail list logo
