Past Stata "platform names" for "package files" (help usersite)

[William Lisowski]

In Stata 16, the output of help usersite tells us about the "g" lines in the package file.

g specifies that the file be installed only if the user's computer is of type platformname; otherwise, the file is ignored. The platform names are WIN64 (64-bit x86-64) for Windows; MACINTEL64 (64-bit Intel, GUI) and OSX.X8664 (64-bit Intel, console) for Mac; and LINUX64 (64-bit x86-64) for Unix.

And this is taken from page 1667 of the Stata Base Reference Manual Release 16.

If however we look at page 1675 of the Stata Base Reference Manual Release 14 we are told

g [...] specifies that the file be installed only if the user’s operating system is of type platformname; otherwise, the file is ignored. The platform names are WIN64A (64-bit x86-64) and WIN (32-bit x86) for Windows; MACINTEL64 (64-bit Intel, GUI), OSX.X8664 (64-bit Intel, console), MACINTEL (32-bit Intel, GUI), and OSX.X86 (32-bit Intel, console) for Mac; and LINUX64 (64-bit x86-64) and LINUX (32-bit x86) for Unix.

Here is the problem I encountered on a recent topic about the synth command. The output of ssc describe synth tells us that it will work with Stata 9.2 or later. The package includes a compiled plugin in versions for the various operating systems, and g lines control which one is installed.

g WIN32 synthopt.win32 synthopt.plugin
g WIN64 synthopt.win64  synthopt.plugin
g LINUX synthopt.linux32 synthopt.plugin
g LINUX64 synthopt.linux64 synthopt.plugin
g MACINTEL64 synthopt.mac synthopt.plugin

The problem arose when a user of Stata 14 for Windows installed the synth package. Their system reported either WIN64A or WIN, neither of which is accommodated within synth.pkg, which dates from July 2018. The end result is that no plugin is installed, and this failure happens quietly. The failure is discovered when synth.ado in its final line executes program synth, plugin and Stata reports that the file synth.plugin is not found.

My guess is that at some point the developers updated the synth.pkg file to accomodate the Stata 15 platform names, but neglected to leave in place the g lines for the older platform names. As a consequence the code can run in Stata 14 but cannot be installed without a workaround.

I want to report this to the developers and would like to be as helpful as possible. I can keep going backward in the PDFs that are available at stata.com, but perhaps someone has a definitive list of the historical platform names and the Stata versions to which they applied.

[Alan Riley (StataCorp)]

... but perhaps someone has a definitive list of the historical platform names and the Stata versions to which they applied.

I'll go back just over 10 years, starting with Stata 11:

WIN: 32-bit Windows
WIN64A: 64-bit Windows on x86-64 hardware
WIN64I: 64-bit Windows on Itanium hardware
MAC: 32-bit PowerPC hardware
AIX: AIX
DECALPHA: DEC Alpha
HP64I: HP-UX on Itanium hardware
LINUX: 32-bit Linux
LINUX64A: 64-bit Linux on x86-64 hardware
LINUX64I: 64-bit Linux on Itanium hardware
SOLARIS: 32-bit Solaris on Sparc hardware
SOL64: 64-bit Solaris on Sparc hardware
SOLX8664: 64-bit Solaris on x86-64 hardware

For Stata 12, that changed to

WIN: 32-bit Windows
WIN64A: 64-bit Windows on x86-64 hardware
MACINTEL: Mac, 32-bit x86 hardware, GUI version
MACINTEL64: Mac, 64-bit x86-64 hardware, GUI version
OSX.X86: Mac, 32-bit x86 hardware, console version
OSX.X8664: Mac, 64-bit x86 hardware, console version
MAC: 32-bit PowerPC hardware, GUI version
OSX.PPC: 32-bit PowerPC hardware, console version
LINUX: 32-bit Linux
LINUX64: 64-bit Linux on x86-64 hardware
SOL64: 64-bit Solaris on Sparc hardware
SOLX8664: 64-bit Solaris on x86-64 hardware

That stayed the same until Stata 15, when some changes were made for clarity, although the older names are still understood. Some older operating systems and hardware platforms were dropped along the way.

WIN32: 32-bit Windows
WIN64: 64-bit Windows on x86-64 hardware
MACINTEL64: Mac, 64-bit x86-64 hardware, GUI version
OSX.X8664: Mac, 64-bit x86 hardware, console version
LINUX: 32-bit Linux
LINUX64: 64-bit Linux on x86-64 hardware

As of Stata 16, only 64-bit platforms are supported:

WIN64: 64-bit Windows on x86-64 hardware
MACINTEL64: Mac, 64-bit x86-64 hardware, GUI version
OSX.X8664: Mac, 64-bit x86 hardware, console version
LINUX64: 64-bit Linux on x86-64 hardware

[William Lisowski]

Wow, what a blast from the past! When was the last time I thought about DEC? This is greatly appreciated.

I will take this opportunity to add to what I wrote earlier, for those who might encounter this topic in the future.

I subsequently learned that good programming practice would be to follow a sequence of g lines like those in post 1 with an h line

h synthopt.plugin

which ensures that if some version of Stata running on a platform not supported by the developer, the installation will not occur, rather than occur incompletely with no warning.

[William Lisowski]

Alan Riley (StataCorp) -

I hope you don't mind a followup question to your generous answer in post #2.

You wrote

... until Stata 15, when some changes were made for clarity, although the older names are still understood.

I had not known this backward compatibility and did not come across reference to it in trying to solve the problem of running ssc install synth from Stata 14 on Windows. And that leads me to the following questions.

Does this mean that Stata 15 and Stata 16 will recognize WIN64A (and WIN) platform names in a package file and treat them as WIN64 (and in Version 15's case, WIN32), so that older packages do not need to be updated to support installation by Windows systems running Stata 15 and Stata 16? In that case the developers of the synth command may have snatched defeat out of the jaws of victory by updating their package on SSC to use Stata 15 platform names, removing the older names, neither of which should have been necessary and the latter of which breaks installation from Windows systems running Stata 14.

If so, what happens if a package contains g lines for both WIN64 and WIN64A and is installed by Windows on 64-bit hardware? Does the potential for two matches that install the same filename cause a problem? Or does Stata "dedupe" the file name list before proceeding?

Thank you again for the advice.

[Alan Riley (StataCorp)]

...

I had not known this backward compatibility and did not come across reference to it in trying to solve the problem of running ssc install synth from Stata 14 on Windows. And that leads me to the following questions.

Does this mean that Stata 15 and Stata 16 will recognize WIN64A (and WIN) platform names in a package file and treat them as WIN64 (and in Version 15's case, WIN32), so that older packages do not need to be updated to support installation by Windows systems running Stata 15 and Stata 16? In that case the developers of the synth command may have snatched defeat out of the jaws of victory by updating their package on SSC to use Stata 15 platform names, removing the older names, neither of which should have been necessary and the latter of which breaks installation from Windows systems running Stata 14.

If so, what happens if a package contains g lines for both WIN64 and WIN64A and is installed by Windows on 64-bit hardware? Does the potential for two matches that install the same filename cause a problem? Or does Stata "dedupe" the file name list before proceeding?

Thank you again for the advice.

That's right. The idea is that if you create a package file for use with, say, Stata 14, newer versions of Stata will still be able to understand that package file.

If you have both WIN64 and WIN64A lines, an old Stata will ignore the WIN64 line it doesn't know anything about. A newer Stata will see both lines and try to install the file twice, but that works out ok as you end up with just one copy of the file when all is said and done.

[Jeroen Albers]

Because I noticed a package (traj from http://www.andrew.cmu.edu/user/bjones/traj/) failing to install on Stata 16.1 for Linux I wonder if the names have changed again. The failure notice is:
package does not contain traj.plugin for LINUX64P platform
Is LINUX64 LINUX64P now?

The documentation still refers to LINUX64, but where can LINUX64P come from then?

[William Lisowski]

I gave it a day thinking perhaps Alan Riley (StataCorp) would see this, but times being what they are, nothing is certain. Since I was involved in the discussion above, let me make a suggestion.

I note that the output of help usersite on Stata 16.1 tells us nothing of LINUX64P

        g specifies that the file be installed only if the user's computer is of type
        platformname; otherwise, the file is ignored.  The platform names are WIN64 (64-bit
        x86-64) for Windows; MACINTEL64 (64-bit Intel, GUI) and OSX.X8664 (64-bit Intel,
        console) for Mac; and LINUX64 (64-bit x86-64) for Unix.

so I suspect this is either unintended or accidentally undocumented.

I recommend you submit this question to Stata Technical Services as described at

https://www.stata.com/support/tech-support/contact/

letting them know precisely the platform on which you are running Stata, and including a link to this discussion so whomever fields the question can build on Alan's previous discussion, and perhaps update this topic.

[Chinh Nguyen (StataCorp)]

Is LINUX64 LINUX64P now?

The documentation still refers to LINUX64, but where can LINUX64P come from then?

LINUX64 is 64-bit Stata for Linux linked with libpng v1.2. LINUX64P is 64-bit Stata for Linux linked with libpng v1.6 and was necessary for newer distributions of Linux that don't come with libpng v1.2.

The installation failure was an oversight. LINUX64 plugins are compatible with LINUX64P Stata although the reverse may not be true. A future update to Stata will have it fall back to LINUX64 if a LINUX64P version does not exist when installing plugins.

[Jeroen Albers]

William and Chinh, thank you both for paying attention to this.

[Jesper Eriksson]

LINUX64 is 64-bit Stata for Linux linked with libpng v1.2. LINUX64P is 64-bit Stata for Linux linked with libpng v1.6 and was necessary for newer distributions of Linux that don't come with libpng v1.2.

The installation failure was an oversight. LINUX64 plugins are compatible with LINUX64P Stata although the reverse may not be true. A future update to Stata will have it fall back to LINUX64 if a LINUX64P version does not exist when installing plugins.

Hi, Sorry if I am posting wrong here. I have the same problem as Jeroen Albers described in post #6

Because I noticed a package (traj from http://www.andrew.cmu.edu/user/bjones/traj/) failing to install on Stata 16.1 for Linux I wonder if the names have changed again. The failure notice is:
package does not contain traj.plugin for LINUX64P platform
Is LINUX64 LINUX64P now?

The documentation still refers to LINUX64, but where can LINUX64P come from then?

I am trying to install the package traj on my Mac M1 laptop. I use it a lot in my research. However, I get the following error message when trying to install:

package does not contain traj.plugin for MACARM64 platform
could not load traj.pkg from http://www.andrew.cmu.edu/user/bjones/traj/
r(601);

Is there anything I can do to solve this problem? This question is cross-posted with

https://www.statalist.org/forums/forum/general-stata-discussion/general/1594742-using-plugins-with-new-version-and-platform

Thank you in advance.

/Jesper Eriksson

[William Lisowski]

There is a response to this on the main topic at

https://www.statalist.org/forums/for...n-and-platform

I will add here that at the time of this writing, help usersite has not been updated to include MACARM64 among the list of potential platform names.

[Chinh Nguyen (StataCorp)]

I am trying to install the package traj on my Mac M1 laptop. I use it a lot in my research. However, I get the following error message when trying to install:

package does not contain traj.plugin for MACARM64 platform
could not load traj.pkg from http://www.andrew.cmu.edu/user/bjones/traj/
r(601);

Is there anything I can do to solve this problem? This question is cross-posted with

https://www.statalist.org/forums/forum/general-stata-discussion/general/1594742-using-plugins-with-new-version-and-platform

Sorry, I just noticed this post. Although Apple Silicon can still run applications built for Intel processors, Apple-Silicon-native applications can't load plugins and shared libraries built for Intel processors. You'll have to ask the author to compile a version of the plugin that's compatible with Apple Silicon (MACARM64), or run Stata under Rosetta 2 (from the Finder, select File > Get Info on the Stata application and and check the Open using Rosetta checkbox).