106806 - plug-in ".sl" extensions not correctly searched on HP-UX 11.00

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Dan Dickerman]

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; HP-UX B.11.00 9000/777)
BuildID:    0.9.5 milestone, built on 2001102415

After compiling with HP's aCC on HP-UX 11.00 with milestone 0.9.5, then creating
a distribution package and running from within the distribution directory, the
shared libraries for plugins (which all end in .sl) are not found. An access
which should load the null plugin presents the message "Netscape cannot find the
Plugin Downloader Plugin...."

One possibility:
modules/plugin/base/src/nsPluginsDirUnix.cpp has an #ifdef block to special-case
the search path for plugins on HP-UX to look for the .sl "shared library"
extension on plugins rather than the .so extension used for plugins on other
Unix platforms.  That ifdef block is used under "if defined(HPUX11)" but it
appears in the 0.9.5 build that this tag is not defined when compiling the C++
under modules/plugin/base/src, however "HPUX" is.

Changing the line in this file from:

#if defined(HPUX11)

  to

#if defined(HPUX11) || defined(HPUX)

Gets the correct HPUX define as:
  #define LOCAL_PLUGIN_DLL_SUFFIX ".sl"
and the plugins all load correctly.

It's worth noting that HP-UX has always used the .sl suffix for shared libraries
(and by extension the plugins for Netscape/Mozilla), so there should be nothing
HPUX11 specific to the .sl extension.  This should be generic to all HPUX
versions.

Other possible issues: should HPUX11 be defined in the environment in this
case?  It is explicitly defined in the nspr-related modules (-DHPUX11 appears on
the compile line), but not in the aCC-compiled modules, nor is it defined
explicitly in the top level autoconf.mk or rules.mk.  It appears we're getting
the HPUX define from the file prcpucfg.h (which does not define HPUX11 or HPUX10
as used elsewhere).  It would be worthwhile to remove all the HPUX11 stuff and
replace it with HPUX in cases like this where the desired feature is not
11.x-specific.


Reproducible: Always
Steps to Reproduce:
1. Build milestone 0.9.5 under HP-UX
2. create a distribution package under xpinstall/packager
3. install distribution in a different directory
4. Reference any page which requires a plugin


Actual Results:  Error window pops-up
"Netscape cannot find the Plugin Downloader Plugin...."

Expected Results:  nullplugin (or other appropriate plugin from ./plugins)
should be found and loaded and run

Comment 1

[Dan Dickerman]

A more obvious way to see the problem, once configured: go to "about:plugins",
where you get the message "no plug-ins are installed"

A few alternate solutions:
 - forget platform-specific extensions for LOCAL_PLUGIN_DLL_SUFFIX, 
   but always search a list of possible extensions, accepting both .so and .sl
   on all platforms.

 - use the same extension as is passed-in for MOZ's own shared libraries,
   as the -DMOZ_DLL_SUFFIX=\".sl\" is defined for the plugin modules

 - Convince HP to change all their shared libraries/plugins to use the .so
   suffix instead of .sl.  This can be done for just the plugins themselves
   as a short-term workaround, pending a recompile.

Comment 2

[Peter Lubczynski]

ouch...we need to special case HP-UX....over to [e-mail]

Comment 3

[Jim Dunn]

accepting...

Comment 4

[Jim Dunn]

The process for building on HP-UX requires certain
defines, see: http://www.mozilla.org/unix/hpux.html

However, as you point out the defines in this file
shouldn't be hpux11 only.  So I will work on fixing
that.

Please note: ns6/mozilla is built using aCC.  The 4.x
plugins used CC, so at this point the existing plugins
available for HP-UX are not compatible with ns6/mozilla.
We are working with the plugin vendors to remedy this.

Comment 5

[Jim Dunn]

I have a better fix for revision 1.16 (# 97362) that
doesn't break hp-ux 10.20.  Basically instead of
defining a new DEFINE, is uses the existing one.
So I removed all references to LOCAL_PLUGIN_DLL_SUFFIX
and replaced it with MOZ_DLL_SUFFIX which gets 
defined in autoconf

NOTE: I added an ifdef AIX section only, since the
change for 97362, broke the loading of AIX's java oji
module.  AIX's oji module ends in ".a" and because
of how ".a" and ".so" are handled during loading
we simply can't rename the .a to a .so and have it work.
So on AIX we MUST look for both the ".so" and the ".a"
extensions.
This is for the trunk...  
I need the r= & sr=

Index: nsPluginsDirUnix.cpp
===================================================================
RCS file: /cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v
retrieving revision 1.20
diff -r1.20 nsPluginsDirUnix.cpp
127d126
< #define LOCAL_PLUGIN_DLL_SUFFIX ".so"
130,131d128
< #undef LOCAL_PLUGIN_DLL_SUFFIX
< #define LOCAL_PLUGIN_DLL_SUFFIX ".sl"
202c199
< #define DEFAULT_EXTRA_LIBS_LIST "libXt" LOCAL_PLUGIN_DLL_SUFFIX ":libXext"
LOCAL_PLUGIN_DLL_SUFFIX
---
> #define DEFAULT_EXTRA_LIBS_LIST "libXt" MOZ_DLL_SUFFIX ":libXext" MOZ_DLL_SUFFIX
311,312c308,309
<         int n = PL_strlen(pathname) - (sizeof(LOCAL_PLUGIN_DLL_SUFFIX) - 1); 
<         if (n > 0 && !PL_strcmp(&pathname[n], LOCAL_PLUGIN_DLL_SUFFIX)) {
---
>         int n = PL_strlen(pathname) - (sizeof(MOZ_DLL_SUFFIX) - 1); 
>         if (n > 0 && !PL_strcmp(&pathname[n], MOZ_DLL_SUFFIX)) {
314a312,320
> #ifdef AIX
>         // on AIX, the oji plugin happens to have a .a extension
>         else {
>           n = PL_strlen(pathname) - 2;
>           if (n > 0 && !PL_strcmp(&pathname[n], ".a")) {
>               ret  = PR_TRUE; // *.a
>           }
>         }
> #endif /* AIX */

Comment 6

[serge (gone)]

Jim, the things is a little bit unclear to me,
mozilla\configure has:
...
 4245     case "${target_os}" in
 4246     aix4.1*)
 4247         DLL_SUFFIX='_shr.a'
...
4623 *-openbsd*)
4624     DLL_SUFFIX=".so.1.0"
...
4892     case "$(target_os)" in
4893     sunos4.1*)
4894         DLL_SUFFIX='.so.1.0'
...
12434 #define MOZ_DLL_SUFFIX "$DLL_SUFFIX"

I doubt that any plugins on sunos4.1 or openbsd have ".so.1.0" suffix,
my suggestion is  to check for ".so",".so.",".sl", ".a" suffixes.
the patch proposal is following

Comment 7

[serge (gone)]

Attachment: serge's patch v1

Comment 8

[Jim Dunn]

I don't think that the patch is quite right...
for what you want.
If you want to look for .so & .so.<blah>  (as 
well as .sl & .sl.<blah> then you should do 2
separate checks.  Because in the openbsd & sunos41
case, you do want to check for both .so & .so*
for HP, I guess u want to search for .sl & .sl*.
And then for AIX, you want to search .so, .so* & .a

we need a better way of checking for HP-UX... ifdef HPUX11
won't do it for us, which is why I wanted to use
MOZ_DLL_SUFFIX (on 10.20 there is no -DHPUX, or anything like it

i need to think about this, I didn't realize that someone
defined MOZ_DLL_SUFFIX=.so.<blah>


 

Comment 9

[hacker formerly known as [e-mail]]

We were told by some openbsd & netbsd contributors that we needed to set the dll
suffix to .so.1.0 for those distributions.  If we needed to make that change to
be seen by the linker, then I would expect that any plugins would need to make
that change as well.  You should probably fallback to checking for .so just in case.
 

Comment 10

[Richard Lloyd]

HP-UX (10.20 or 11.00) uses ".sl" or ".number" (e.g. ".1", ".2" etc.) -
it doesn't use any extension to ".sl" or ".number" (though I've seen
libtool and the like wrongly do this on HP-UX).

However, it should be noted that the dynamic loader doesn't actually 
care what the extension is at all, as long as it finds the basename (either
in the embedded path in the binary or via the SHLIB_PATH environmental
variable if the binary's been linked to pick it up or the binary's been
chatr'ed after the link).

Comment 11

[serge (gone)]

#8 >If you want to look for .so & .so.<blah> ... then you should do 2 separate 
checks
Why? I think the next code handles it properly:
...
    349             //check for ".so",".so.",".sl", ".sl.", ".a" suffixes.
    350             if (filename[i] == 0 || filename[i] == '.') {
    351                 int n = i - suffixLen;
    352                 if (n > 0) {
    353                     if (!PL_strncmp(&filename[n], 
LOCAL_PLUGIN_DLL_SUFFIX, suffixLen)) {
    354                         ret  = PR_TRUE;
    355                         break;
    356                     }
...
#8 >on 10.20 there is no -DHPUX, or anything like it 
that's not good at all:(

#9 >You should probably fallback to checking for .so just in case.
absolutely agree, moreover we have to check for *.so.<numbers> 
as it's valid name for shard library, and MOZ_DLL_SUFFIX is subset of those 
valid suffixes. Sure we can use MOZ_DLL_SUFFIX extract last ".so[sl][.]" 
substring from it and do the right comparison.

Comment 12

[Dan Dickerman]

> on 10.20 there is no -DHPUX, or anything like it 
> that's not good at all:(

If it's of any help, HP's cpp on both 10.x and 11.x will automatically define
several architecture-flagging symbols, detailed on the cpp(1) man page.  
Among these: "All HP-UX systems have the symbols PWB, hpux, unix, _PWB,
__hpux, and __unix defined"  So I believe using the automatic "hpux" in 
place of -DHPUX would get what you're after.

Comment 13

[Jim Dunn]

actually "hpux" is not defined but "__hpux" is  (note no "'s)

Comment 14

[Jim Dunn]

Attachment: new patch to address the problem

If we use the _hpux ifdef, this is picked up by both 10.20 & 11.00.

Also, in the case of a couple of OS's, if  LOCAL_PLUGIN_DLL_SUFFIX
is different than MOZ_DLL_SUFFIX then see if the file ends in
MOZ_DLL_SUFFIX also.  This helps the case of darwin's ".dylib",
freebsd's, openbsd's, sunos's  & netbsd's ".so.1.0" and AIX's ".a".

Comment 15

[serge (gone)]

Comment on attachment 67096 [details] [diff] [review]
new patch to address the problem

looks good to me, r=serge

Comment 16

[Patrick C. Beard]

Comment on attachment 67096 [details] [diff] [review]
new patch to address the problem

Couple of comments:
1. why are some _AIX changes coming in on this patch.
2. isn't there a compile time way to do PL_strcmp(LOCAL_PLUGIN_DLL_SUFFIX,
MOZ_DLL_SUFFIX) instead of comparing 2 string constants?

Comment 17

[Jim Dunn]

The aix change is coming to in kill 2 birds with one stone.
AIX's java plugin ends with a ".a" which WE no longer load
because of the previous checkin...

Not sure how to do a compile ifdef check to see if these 
are the same.

This whole IsPlugin function is wrong... but to fix the
problem, we have to remove it and then handle the loading
of a non plugin file.  I started looking at this but the
code got very confusing very quickly.  If you want I
can go down that route.  

Comment 18

[serge (gone)]

Oh, yes I overlooked that, I think
PL_strcmp(LOCAL_PLUGIN_DLL_SUFFIX, MOZ_DLL_SUFFIX) 
is not necessary at all
>...and then handle the loading of a non plugin file...
Do you mean we have to check file magic number?

Comment 19

[serge (gone)]

*** Bug 129323 has been marked as a duplicate of this bug. ***

Comment 20

[serge (gone)]

nominating

Comment 21

[Philip K. Warren]

I believe this will still cause problems on AIX because it should recognize both
".a" and ".so" as possible plugin extensions.

Comment 22

[serge (gone)]

Is this not true for aix MOZ_DLL_SUFFIX==.so ?

Comment 23

[Philip K. Warren]

Nevermind. This should work fine for AIX.

Comment 24

[Winnie Lam]

plusing this bug as per adt plug-ins triage since there is a patch for it.

Comment 25

[Philip K. Warren]

Attachment: New patch

This patch defines LOCAL_PLUGIN_DLL_ALT_SUFFIX for platforms like AIX and HP-UX
which have plugins which can end in different suffixes.

Comment 26

[Jim Dunn]

this is great... it fixes both AIX & HP-UX...
r=[e-mail]

Comment 27

[Dan Dickerman]

And allows both .sl and .so suffixes on UX, as some folks deliver one and some
folks deliver the other.  Works for me...

Comment 28

[Philip K. Warren]

Attachment: Final patch

This is just a small change from the previous patch. This obseletes 83055. The
default extension for plugins on AIX should be ".so", with the alternate being
".a".

Comment 29

[Jim Dunn]

serge,av can I get an sr= for the trunk?

Comment 30

[serge (gone)]

Comment on attachment 83579 [details] [diff] [review]
Final patch

>         if (n > 0 && !PL_strcmp(&pathname[n], LOCAL_PLUGIN_DLL_SUFFIX)) {
>             ret  = PR_TRUE; // *.so or *.sl file
>         }
>+
>+#ifdef LOCAL_PLUGIN_DLL_ALT_SUFFIX
I would use
     if (!ret) {
>+        n = PL_strlen(pathname) - (sizeof(LOCAL_PLUGIN_DLL_ALT_SUFFIX) - 1);
>+        if (n > 0 && !PL_strcmp(&pathname[n], LOCAL_PLUGIN_DLL_ALT_SUFFIX)) {
>+            ret = PR_TRUE;
>+        }
      }
to increase the performance
>+#endif
>+
> #ifdef NS_DEBUG
>         printf("IsPluginFile(%s) == %s\n", pathname, ret?"TRUE":"FALSE");
> #endif

with that r=serge

Comment 31

[Jim Dunn]

fix checked in with serge's suggestion

Comment 32

[Jim Dunn]

*** Bug 51376 has been marked as a duplicate of this bug. ***

Comment 33

[Martin Lawyer]

*** Bug 151594 has been marked as a duplicate of this bug. ***

Comment 34

[shrirang khanzode]

.