bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / code / Atom feed
* Makefile operator -ot generate-parse-datetime tru64
@ 2021-06-29  8:17 Jay K
  2021-06-29  8:24 ` getprocname Tru64 Jay K
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Jay K @ 2021-06-29  8:17 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Larkin Nickle

I'm building GNU tar on Tru64.
> uname -srm
OSF1 V5.1 alpha

The operator -ot causes errors.

Can you state this stuff more portability?

I'm doing this, which I realize is the wrong file, at least, and maybe not ideal otherwise,
otherwise you would not be using -ot:


> diff  Makefile.in.orig Makefile.in
2896c2896
<       @{ test -f $(srcdir)/parse-datetime.c && test ! $(srcdir)/parse-datetime.c -ot $(srcdir)/parse-datetime.y; } || $(MAKE) generate-parse-datetime
---
>       $(MAKE) generate-parse-datetime
2898c2898
<       @{ test -f $(srcdir)/parse-datetime-gen.h && test ! $(srcdir)/parse-datetime-gen.h -ot $(srcdir)/parse-datetime.c; } || $(MAKE) generate-parse-datetime
---
>       $(MAKE) generate-parse-datetime

Sure, eventually I'll have GNU make, bash, etc., and I should cross build, but I am starting with tar, natively.

Thank you,
  - Jay

^ permalink raw reply	[flat|nested] 6+ messages in thread

* getprocname Tru64
  2021-06-29  8:17 Makefile operator -ot generate-parse-datetime tru64 Jay K
@ 2021-06-29  8:24 ` Jay K
  2021-06-29 15:04   ` Bruno Haible
  2021-06-29 14:52 ` Makefile operator -ot generate-parse-datetime tru64 Bruno Haible
  2021-07-01 17:41 ` Paul Eggert
  2 siblings, 1 reply; 6+ messages in thread
From: Jay K @ 2021-06-29  8:24 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Larkin Nickle

I see I lost the race here, but here is my rendition of getprogname for Tru64, much more efficient.

> diff -c getprogname.c.orig getprogname.c
*** getprogname.c.orig  Tue Jun 29 03:46:44 2021
--- getprogname.c       Tue Jun 29 03:48:55 2021
***************
*** 283,288 ****
--- 283,291 ----
        close (fd);
      }
    return "?";
+ # elif defined __osf__
+   extern char** __Argv;
+   return last_component (__Argv[0]);
  # else

I came to this by:
1: Looked in old gcc to find:
#define MD_STARTFILE_PREFIX "/usr/lib/cmplrs/cc/"

2: grep/nm/dis there.

I had hoped to step through the startup but haven't learned this dbx yet.

There is also maybe "auxv" stuff.

I find the proc file system kinda gross and inefficient but yeah.

Thank you,
 - Jay




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Makefile operator -ot generate-parse-datetime tru64
  2021-06-29  8:17 Makefile operator -ot generate-parse-datetime tru64 Jay K
  2021-06-29  8:24 ` getprocname Tru64 Jay K
@ 2021-06-29 14:52 ` Bruno Haible
  2021-07-01 17:41 ` Paul Eggert
  2 siblings, 0 replies; 6+ messages in thread
From: Bruno Haible @ 2021-06-29 14:52 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Jay K, Larkin Nickle

Hi,

> I'm building GNU tar on Tru64.
> > uname -srm
> OSF1 V5.1 alpha

Note that we dropped support of this platform two years ago. [1]

This means: while we may apply patches that look right and don't
have impact on other platforms, we won't have time to discuss
more complex issues.

> The operator -ot causes errors.
> 
> Can you state this stuff more portability?

Unfortunately no. It was a big challenge already to come up
with a solution of the parallel-build problem that did not
rely on GNU make nor on extra utilities. [2]

> I'm doing this, which I realize is the wrong file, at least, and maybe not ideal otherwise,
> otherwise you would not be using -ot:
> 
> 
> > diff  Makefile.in.orig Makefile.in
> 2896c2896
> <       @{ test -f $(srcdir)/parse-datetime.c && test ! $(srcdir)/parse-datetime.c -ot $(srcdir)/parse-datetime.y; } || $(MAKE) generate-parse-datetime
> ---
> >       $(MAKE) generate-parse-datetime
> 2898c2898
> <       @{ test -f $(srcdir)/parse-datetime-gen.h && test ! $(srcdir)/parse-datetime-gen.h -ot $(srcdir)/parse-datetime.c; } || $(MAKE) generate-parse-datetime
> ---
> >       $(MAKE) generate-parse-datetime
> 
> Sure, eventually I'll have GNU make, bash, etc., and I should cross build, but I am starting with tar, natively.

Yup. When you are bootstrapping a port of several utilities, you have
to make temporary workarounds.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2019-07/msg00030.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00046.html



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: getprocname Tru64
  2021-06-29  8:24 ` getprocname Tru64 Jay K
@ 2021-06-29 15:04   ` Bruno Haible
  2021-07-06 11:25     ` Jay K
  0 siblings, 1 reply; 6+ messages in thread
From: Bruno Haible @ 2021-06-29 15:04 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Jay K, Larkin Nickle

Jay K wrote:
> I see I lost the race here, but here is my rendition of getprogname for Tru64, much more efficient.
> 
> > diff -c getprogname.c.orig getprogname.c
> *** getprogname.c.orig  Tue Jun 29 03:46:44 2021
> --- getprogname.c       Tue Jun 29 03:48:55 2021
> ***************
> *** 283,288 ****
> --- 283,291 ----
>         close (fd);
>       }
>     return "?";
> + # elif defined __osf__
> +   extern char** __Argv;
> +   return last_component (__Argv[0]);
>   # else

But it seems that the use '__Argv' can cause link-time errors on Tru64. [1]

> I came to this by:
> 1: Looked in old gcc to find:
> #define MD_STARTFILE_PREFIX "/usr/lib/cmplrs/cc/"
> 
> 2: grep/nm/dis there.
> 
> I had hoped to step through the startup but haven't learned this dbx yet.

In other words, it's undocumented. In Gnulib, we avoid to rely on
undocumented stuff when possible. In some cases it is unavoidable,
but here we already have an implementation of getprogname() for
OSF/1.

> There is also maybe "auxv" stuff.

That's not good. The result would not only depend on which executable
is running, but on how it was invoked (shell, emulator, valgrind, etc.).

> I find the proc file system kinda gross and inefficient but yeah.

If it's inefficient, you can add caching via a 'static' variable.
Like we already do in the implementations for AIX and HP-UX.

Bruno

[1] https://stat.ethz.ch/pipermail/r-help//2004-January/044699.html



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Makefile operator -ot generate-parse-datetime tru64
  2021-06-29  8:17 Makefile operator -ot generate-parse-datetime tru64 Jay K
  2021-06-29  8:24 ` getprocname Tru64 Jay K
  2021-06-29 14:52 ` Makefile operator -ot generate-parse-datetime tru64 Bruno Haible
@ 2021-07-01 17:41 ` Paul Eggert
  2 siblings, 0 replies; 6+ messages in thread
From: Paul Eggert @ 2021-07-01 17:41 UTC (permalink / raw)
  To: Jay K, bug-gnulib; +Cc: Larkin Nickle

On 6/29/21 1:17 AM, Jay K wrote:
> The operator -ot causes errors.

It's OK if 'test ! B -ot A' issues a diagnostic on your old platform, so 
long as it fails (exits with nonzero status) when that happens. In that 
case, some extra work will be done by 'make' because -ot is not 
supported, but that's merely a minor inefficiency; it's not a 
correctness problem. And given that your platform is so old it's no 
longer supported, we don't need to worry about minor inefficiencies like 
that.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: getprocname Tru64
  2021-06-29 15:04   ` Bruno Haible
@ 2021-07-06 11:25     ` Jay K
  0 siblings, 0 replies; 6+ messages in thread
From: Jay K @ 2021-07-06 11:25 UTC (permalink / raw)
  To: Bruno Haible, bug-gnulib; +Cc: Larkin Nickle

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

 > emulator

Do emulators like, are the process/executable from the kernel
point of view but implement their own loaders and load an executable? ok.
They should intercept aux queries though.

> link error

True it is a warning when building .so, and then
*tends* to work with all executables, given the same startup code.
I guess someone could write their own.

 > undocumented

Indeed.

I am not sure of the O_CLOEXEC there.
I know the intent, but I don't think it is a thing on Tru64/OSF1.

Other than removing O_CLOEXEC I tested the code and it works.

Thank you,
 - Jay

________________________________
From: Bruno Haible <bruno@clisp.org>
Sent: Tuesday, June 29, 2021 3:04 PM
To: bug-gnulib@gnu.org <bug-gnulib@gnu.org>
Cc: Jay K <jayk123@hotmail.com>; Larkin Nickle <me@larbob.org>
Subject: Re: getprocname Tru64

Jay K wrote:
> I see I lost the race here, but here is my rendition of getprogname for Tru64, much more efficient.
>
> > diff -c getprogname.c.orig getprogname.c
> *** getprogname.c.orig  Tue Jun 29 03:46:44 2021
> --- getprogname.c       Tue Jun 29 03:48:55 2021
> ***************
> *** 283,288 ****
> --- 283,291 ----
>         close (fd);
>       }
>     return "?";
> + # elif defined __osf__
> +   extern char** __Argv;
> +   return last_component (__Argv[0]);
>   # else

But it seems that the use '__Argv' can cause link-time errors on Tru64. [1]

> I came to this by:
> 1: Looked in old gcc to find:
> #define MD_STARTFILE_PREFIX "/usr/lib/cmplrs/cc/"
>
> 2: grep/nm/dis there.
>
> I had hoped to step through the startup but haven't learned this dbx yet.

In other words, it's undocumented. In Gnulib, we avoid to rely on
undocumented stuff when possible. In some cases it is unavoidable,
but here we already have an implementation of getprogname() for
OSF/1.

> There is also maybe "auxv" stuff.

That's not good. The result would not only depend on which executable
is running, but on how it was invoked (shell, emulator, valgrind, etc.).

> I find the proc file system kinda gross and inefficient but yeah.

If it's inefficient, you can add caching via a 'static' variable.
Like we already do in the implementations for AIX and HP-UX.

Bruno

[1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fpipermail%2Fr-help%2F%2F2004-January%2F044699.html&amp;data=04%7C01%7C%7C862a06f8085c48b64b3e08d93b0f34a7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605758753944531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=UT6O%2Bb32VETYGALCLYynBm0oamrOehw2wjLwcqsgI0I%3D&amp;reserved=0


[-- Attachment #2: Type: text/html, Size: 4739 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-07-06 11:33 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-29  8:17 Makefile operator -ot generate-parse-datetime tru64 Jay K
2021-06-29  8:24 ` getprocname Tru64 Jay K
2021-06-29 15:04   ` Bruno Haible
2021-07-06 11:25     ` Jay K
2021-06-29 14:52 ` Makefile operator -ot generate-parse-datetime tru64 Bruno Haible
2021-07-01 17:41 ` Paul Eggert

Code repositories for project(s) associated with this inbox:

	../../../mirrors/gnulib.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).