public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [VMS/committed]: Set extension to archive member
@ 2012-04-17 11:27 Tristan Gingold
  2012-04-17 12:36 ` h.becker
  2012-04-17 16:48 ` Douglas B Rupp
  0 siblings, 2 replies; 7+ messages in thread
From: Tristan Gingold @ 2012-04-17 11:27 UTC (permalink / raw)
  To: binutils Development

Hi,

VMS archives member names doesn't have extension (only the 'basename' is stored).
But this is not the usual convention for ar, and some tools (libtool) expect that extracted
members of an archive to have the standard object extension.

This patch implements this behaviour, thus making VMS archives more UNIX friendly.

Committed on trunk.

Tristan.

bfd/
2012-04-17  Tristan Gingold  <gingold@adacore.com>

	* vms-lib.c (_bfd_vms_lib_get_module): Append .obj extension to
	member of an object archive.<

Index: vms-lib.c
===================================================================
RCS file: /cvs/src/src/bfd/vms-lib.c,v
retrieving revision 1.21
diff -c -p -r1.21 vms-lib.c
*** vms-lib.c	17 Apr 2012 10:28:19 -0000	1.21
--- vms-lib.c	17 Apr 2012 10:47:01 -0000
*************** _bfd_vms_lib_get_module (bfd *abfd, unsi
*** 1296,1301 ****
--- 1296,1302 ----
    struct lib_tdata *tdata = bfd_libdata (abfd);
    bfd *res;
    file_ptr file_off;
+   char *name;
  
    /* Sanity check.  */
    if (modidx >= tdata->nbr_modules)
*************** _bfd_vms_lib_get_module (bfd *abfd, unsi
*** 1357,1363 ****
        res->origin = file_off + tdata->mhd_size;
      }
  
!   res->filename = tdata->modules[modidx].name;
  
    tdata->cache[modidx] = res;
  
--- 1358,1382 ----
        res->origin = file_off + tdata->mhd_size;
      }
  
!   /* Set filename.  */
!   name = tdata->modules[modidx].name;
!   switch (tdata->type)
!     {
!     case LBR__C_TYP_IOBJ:
!     case LBR__C_TYP_EOBJ:
!       /* For object archives, append .obj to mimic standard behaviour.  */
!       {
! 	size_t namelen = strlen (name);
! 	char *name1 = bfd_alloc (res, namelen + 4 + 1);
! 	memcpy (name1, name, namelen);
! 	strcpy (name1 + namelen, ".obj");
! 	name = name1;
!       }
!       break;
!     default:
!       break;
!     }
!   res->filename = name;
  
    tdata->cache[modidx] = res;
  

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

* Re: [VMS/committed]: Set extension to archive member
  2012-04-17 11:27 [VMS/committed]: Set extension to archive member Tristan Gingold
@ 2012-04-17 12:36 ` h.becker
  2012-04-17 13:34   ` Tristan Gingold
  2012-04-17 16:48 ` Douglas B Rupp
  1 sibling, 1 reply; 7+ messages in thread
From: h.becker @ 2012-04-17 12:36 UTC (permalink / raw)
  To: binutils

On 04/17/12 12:50, Tristan Gingold wrote:
> VMS archives member names doesn't have extension (only the 'basename' is stored).
> But this is not the usual convention for ar, and some tools (libtool) expect that extracted
> members of an archive to have the standard object extension.
>
> This patch implements this behaviour, thus making VMS archives more UNIX friendly.

It's not obvious to me whether the change adds the object extension to 
the member name or if it is added just for extracting a member. Adding 
it to the member name will make the library somehow "unusal" for VMS. It 
may break tools like MMS and it sure will confuse VMS users. It may not 
break the VMS linker, but I didn't check.

For what it is worth, VMS object libraries contain object modules. The 
name of the module is determined on VAX and Alpha: by the [e]mh$t_name 
in the object module header record; on I64: by the NT_VMS_MHD entry in 
the notes section. The object language, as documented in the Linker 
manual, only restricts the length of the module name: 31 characters. It 
is up to the tool which generates the object module - in VMS terms the 
language processor - to write this module header. Usually the language 
processors allow the users to specify the module name, for example C 
with "#pragma module". (The HP C compiler expects a C identifier for 
this #pragma, which is a HP C compiler limitation). All language 
processors have default values, for the case that a user doesn't specify 
a name. Some but not all language processors use the basename. VAX macro 
for example uses ".MAIN.", which is not a valid ODS2 basename. The C 
compiler uses the basename. For ODS5 disks this can result in funny 
module names for C sources like "a.b.c".

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

* Re: [VMS/committed]: Set extension to archive member
  2012-04-17 12:36 ` h.becker
@ 2012-04-17 13:34   ` Tristan Gingold
  0 siblings, 0 replies; 7+ messages in thread
From: Tristan Gingold @ 2012-04-17 13:34 UTC (permalink / raw)
  To: h.becker; +Cc: binutils


On Apr 17, 2012, at 2:32 PM, h.becker wrote:

> On 04/17/12 12:50, Tristan Gingold wrote:
>> VMS archives member names doesn't have extension (only the 'basename' is stored).
>> But this is not the usual convention for ar, and some tools (libtool) expect that extracted
>> members of an archive to have the standard object extension.
>> 
>> This patch implements this behaviour, thus making VMS archives more UNIX friendly.
> 
> It's not obvious to me whether the change adds the object extension to the member name or if it is added just for extracting a member. Adding it to the member name will make the library somehow "unusal" for VMS. It may break tools like MMS and it sure will confuse VMS users. It may not break the VMS linker, but I didn't check.

It is added just when a member is extracted.  Therefore the library looks usual to the VMS linker (or to librarian).

> For what it is worth, VMS object libraries contain object modules. The name of the module is determined on VAX and Alpha: by the [e]mh$t_name in the object module header record; on I64: by the NT_VMS_MHD entry in the notes section. The object language, as documented in the Linker manual, only restricts the length of the module name: 31 characters. It is up to the tool which generates the object module - in VMS terms the language processor - to write this module header. Usually the language processors allow the users to specify the module name, for example C with "#pragma module". (The HP C compiler expects a C identifier for this #pragma, which is a HP C compiler limitation). All language processors have default values, for the case that a user doesn't specify a name. Some but not all language processors use the basename. VAX macro for example uses ".MAIN.", which is not a valid ODS2 basename. The C compiler uses the basename. For ODS5 disks this can result in funny module names for C sources like "a.b.c".

Although many VMS #pragma are now implemented in gcc, #pragma module isn't.  We currently set the module name from the basename of the file.

Tristan.

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

* Re: [VMS/committed]: Set extension to archive member
  2012-04-17 11:27 [VMS/committed]: Set extension to archive member Tristan Gingold
  2012-04-17 12:36 ` h.becker
@ 2012-04-17 16:48 ` Douglas B Rupp
  2012-04-18  7:13   ` Tristan Gingold
  1 sibling, 1 reply; 7+ messages in thread
From: Douglas B Rupp @ 2012-04-17 16:48 UTC (permalink / raw)
  To: Tristan Gingold; +Cc: binutils Development

On 4/17/2012 3:50 AM, Tristan Gingold wrote:
> Hi,
>
> VMS archives member names doesn't have extension (only the 'basename' is stored).
> But this is not the usual convention for ar, and some tools (libtool) expect that extracted
> members of an archive to have the standard object extension.
>
> This patch implements this behaviour, thus making VMS archives more UNIX friendly.
>
> Committed on trunk.
>
> Tristan.

So if one inserts a .o, it extracts as a .obj?

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

* Re: [VMS/committed]: Set extension to archive member
  2012-04-17 16:48 ` Douglas B Rupp
@ 2012-04-18  7:13   ` Tristan Gingold
  2012-04-18  7:18     ` h.becker
  0 siblings, 1 reply; 7+ messages in thread
From: Tristan Gingold @ 2012-04-18  7:13 UTC (permalink / raw)
  To: Douglas B Rupp; +Cc: binutils Development


On Apr 17, 2012, at 6:23 PM, Douglas B Rupp wrote:

> On 4/17/2012 3:50 AM, Tristan Gingold wrote:
>> Hi,
>> 
>> VMS archives member names doesn't have extension (only the 'basename' is stored).
>> But this is not the usual convention for ar, and some tools (libtool) expect that extracted
>> members of an archive to have the standard object extension.
>> 
>> This patch implements this behaviour, thus making VMS archives more UNIX friendly.
>> 
>> Committed on trunk.
>> 
>> Tristan.
> 
> So if one inserts a .o, it extracts as a .obj?

Yes.  That looks strange, but the extension is lost in the archive.


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

* Re: [VMS/committed]: Set extension to archive member
  2012-04-18  7:13   ` Tristan Gingold
@ 2012-04-18  7:18     ` h.becker
  2012-04-18  7:37       ` Tristan Gingold
  0 siblings, 1 reply; 7+ messages in thread
From: h.becker @ 2012-04-18  7:18 UTC (permalink / raw)
  To: binutils

On 04/18/12 08:33, Tristan Gingold wrote:
>
> On Apr 17, 2012, at 6:23 PM, Douglas B Rupp wrote:
>
>> On 4/17/2012 3:50 AM, Tristan Gingold wrote:
>>> Hi,
>>>
>>> VMS archives member names doesn't have extension (only the 'basename' is stored).
>>> But this is not the usual convention for ar, and some tools (libtool) expect that extracted
>>> members of an archive to have the standard object extension.
>>>
>>> This patch implements this behaviour, thus making VMS archives more UNIX friendly.
>>>
>>> Committed on trunk.
>>>
>>> Tristan.
>>
>> So if one inserts a .o, it extracts as a .obj?
>
> Yes.  That looks strange, but the extension is lost in the archive.
>
>
Hmm, as I tried to explain, it's a feature of VMS object libraries. The 
extension may change as well as the basename may change - because of 
differences between the module name and the basename - and as you may 
end up with many library members from just one object file.

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

* Re: [VMS/committed]: Set extension to archive member
  2012-04-18  7:18     ` h.becker
@ 2012-04-18  7:37       ` Tristan Gingold
  0 siblings, 0 replies; 7+ messages in thread
From: Tristan Gingold @ 2012-04-18  7:37 UTC (permalink / raw)
  To: h.becker; +Cc: binutils


On Apr 18, 2012, at 9:09 AM, h.becker wrote:

> On 04/18/12 08:33, Tristan Gingold wrote:
>> 
>> On Apr 17, 2012, at 6:23 PM, Douglas B Rupp wrote:
>> 
>>> On 4/17/2012 3:50 AM, Tristan Gingold wrote:
>>>> Hi,
>>>> 
>>>> VMS archives member names doesn't have extension (only the 'basename' is stored).
>>>> But this is not the usual convention for ar, and some tools (libtool) expect that extracted
>>>> members of an archive to have the standard object extension.
>>>> 
>>>> This patch implements this behaviour, thus making VMS archives more UNIX friendly.
>>>> 
>>>> Committed on trunk.
>>>> 
>>>> Tristan.
>>> 
>>> So if one inserts a .o, it extracts as a .obj?
>> 
>> Yes.  That looks strange, but the extension is lost in the archive.
>> 
>> 
> Hmm, as I tried to explain, it's a feature of VMS object libraries. The extension may change as well as the basename may change - because of differences between the module name and the basename - and as you may end up with many library members from just one object file.

Yes, I think that I understand that.
Contrary to VMS librarian, GNU ar use the filename to set member name (and not the module name).  In practice, this doesn't change anything as basename = module name.  I agree this is not fully compliant with VMS librarian, but that's UNIX tools ported to VMS.

Tristan.


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

end of thread, other threads:[~2012-04-18  7:18 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-17 11:27 [VMS/committed]: Set extension to archive member Tristan Gingold
2012-04-17 12:36 ` h.becker
2012-04-17 13:34   ` Tristan Gingold
2012-04-17 16:48 ` Douglas B Rupp
2012-04-18  7:13   ` Tristan Gingold
2012-04-18  7:18     ` h.becker
2012-04-18  7:37       ` Tristan Gingold

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).