From: UnixOS2 Archive
To: "UnixOS2 Archive" <UnixOS2_Archive at unixos2.com>
Date: Thu, 3 Oct 2002 04:39:03 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 334

**************************************************
Wednesday 02 October 2002
 Number  334
**************************************************

Subjects for today
 
1  Re: Aw: Re:  Some news : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
2   gcc 3.0.3 generates strange outfile names : Thomas Hoffmann <thoffman at zappa.sax.de>
3   Perl 5.8.0 binary : Thomas Hoffmann <thoffman at zappa.sax.de>

**= Email   1 ==========================**

Date:  Thu, 3 Oct 2002 17:37:40 +0200 (CEST)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re: Aw: Re:  Some news

On Wed, 2 Oct 2002 andreas.buening at nexgo.de wrote:

> How it basically works: You initialize a specific struct that contains
> some "to do" flags,
(more explanations snipped)

Thanks for info.

> > shared/object, DLL under OS/2? Under Unix I can use fork, under
> > Windows I can spawn  "rundll32 my_dll,startup_function_of_child"
> 
> Never heard of it. I use spawn...() for this purpose.

Well, the drawback is that it requires that you have an executable.
In my case I just have a DLL and nothing else. Windows' rundll32.exe
is a rather clever idea to cover that gap in the native API, I assume
it consists just of something like
int main(argc, argv)
{
  /* Load my_dll, aka "dlopen" */
  /* resolve symbol startup_function_of_child, aka "dlsym" */
  startup_function_of_child();
  return 0;
}

No problem to write such a beast on OS/2 (presumably), but delivering
just a DLL, not a DLL plus an executable which must be installed in
the "right" place was the whole point of the question. So I'll just stay
with fork (and its inefficiencies) for the OS/2 case... 

	Regards,
		Stefan


**= Email   2 ==========================**

Date:  Thu, 03 Oct 2002 21:20:32 +0100
From:  Thomas Hoffmann <thoffman at zappa.sax.de>
Subject:   gcc 3.0.3 generates strange outfile names

In the old days a command line like 
  gcc emil.c
generated an executable named a.out.

Now gcc 3.0.3 tries to be cute and generates an executable named
emil.exe.

Even when adding a library to the command line:
  gcc emil.c -lcext
it generates emil.exe.

But beware: when reversing the position of filename and option the
generated filename is rather strange:
  gcc -lcext emil.c 
generates -lcext.exe.

This has ruined my attempt to configure a software package, so is there
any chance to get this fixed,
maybe by generating the old dumb name a.out?

I have no clue if the definitions have changed, but in the gcc 2.8.1
days the docs clearly stated:

-o file 
......

If '-o' is not specified, the default is to put an executable file in
'a.out', the object file for 
'source.suffix' in 'source.o', its assembler file in 'source.s', and all
preprocessed C source on standard output. 

-- 
Thomas Hoffmann                                    Telephone:
49-351-4598831
thoffman at zappa.sax.de                                       Dresden,
Germany

..sig under construction ...

**= Email   3 ==========================**

Date:  Thu, 03 Oct 2002 22:16:08 +0100
From:  Thomas Hoffmann <thoffman at zappa.sax.de>
Subject:   Perl 5.8.0 binary

On usenet I read some minutes ago:

....
On Sat, 20 Jul 2002 11:49:09 UTC, John Poltorak <jp at eyup.org> wrote:

> Perl 5.8.0 has just been released, and thanks to some last minute 
> changes, builds pretty well on OS/2.
....


What about providing a pre-built Perl 5.8.0 for people that just would
like to
use this sofware for building other stuff (vs. people that are after
permanent "proofs of concept")? And if this binary distro would fit into
the frame of FHS, this would even be better.

Just dreaming ....;-)


-- 
Thomas Hoffmann                                    Telephone:
49-351-4598831
thoffman at zappa.sax.de                                       Dresden,
Germany

..sig under construction ...