8568 - Unix: library name collosions

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Roland Mainz]

Simple problem: I tried to hack-in a plugin which reads XML-based medical data.
Problem: The software (commercial) includes already a library - called
"libreg.so".

IMHO it should be better to give Mozilla's private libraries more meaningfull
names, e.g. "libMozReg.so" instead of "libreg.so".

Marked as critical because SuSe Linux 6.1 (Kernel 2.2 ?) HANGS after this name
collision. Something very bad did happen there... RedHat wasn't more
successfull. I'll try to figure out if a bug report to the Linux kernel folks is
neccesary...

Component set to "Build Config" - AFAIK this is only a big rename action in the
build configs...

Older Solaris builds simply filed me a core :-(  and newer cannot be tested due
Bug 8413.

Playing with the LD_LIBRARY_PATH and the positions of Mozilla's libraries,
/usr/local/lib and the other software's library directory did not solve the
problem :-(

Comment 1

[Brian Ostrom]

I could make this simple change, but Dan is the right person to
do it.

Comment 2

[Daniel Veditz [:dveditz]]

reassigning to mcafee as a likely unix-knowledgable person.

I don't mind changing the libreg module name so much, but I'm concerned about
1) why this crashes and 2) why this isn't a potential problem for ALL our
libraries. So we rename libreg because of the conflict with this medical
package, what do we have to rename next week?  Is there a systematic fix that
would cover this problem in general?

Comment 3

[Roland Mainz]

1. No crash, but this causes the Linux-x86-boxes to hang - making it impossible
for me to use gdb :-(

2. A systematic fix would be to give them a really unique name, e.g. libMozReg
instead of libreg, e.g. all Unix libraries which are Mozilla _private_ start
with libMoz*.

Comment 4

[Chris McAfee]

I think we should rename the library.
It's pretty harmless and solves the problem.

To answer Dan's question "what do we rename next week",
we have not named our libraries very carefully and may
have other conflicts.  Scoping things with "Moz" will
fix the generic names once and for all.  Back to briano
for the fix.

Comment 5

[Roland Mainz]

Question: Does Unix allow uppercase letters in library names ? (or would break
this a 20-year tradition ?? =:-)  )
Then I would prefer the JAVA-style naming which is used for JAVA classes/method
names, e.g. libMozReg.so instead of libmozreg.so.

--

Small note BEFORE the wild renaming party: Public libraries (libexpat ??,
libjpeg etc.) should NOT be renamed.

Comment 6

[Chris Yeh]

too close to milestone to do mass library renaming. pushing to M9

Comment 7

[Brian Ostrom]

If everyone thinks the name change is acceptable, then I will go
ahead and rename it "libmozreg.so" and fix all the references to
it throughout the code.

Comment 8

[Brian Ostrom]

This bug is Unix-specific, but I think it'd be a good idea to be consistent
across all the platforms with respect to the library name.  I think this is
probably not an issue on Mac (or at least trivial to change), but I don't
know what to do on Windows.  Don't we need to limit the name length to 8.3?
If so, then "libmozreg.dll" can't be used.  Does library name consistency
even matter?  Do we care?  Should I just be quiet and fix just the Unix bug?

Comment 9

[Daniel Veditz [:dveditz]]

Typically on Windows we don't prefix the libraries with "lib" anymore, so
"mozreg.dll" would seem to be fine. The "32" part of libreg32.dll needs to go
away also.

Comment 10

[ramiro]

Brian,

Thanks for fixing this.  I did the same thing a long time ago for libutil and
libjs.  I changed them to lib$(SOMETHING)js and lib$(SOMETHING)util.  I then set
SOMETHING=moz in config/autoconf.mk.in.

Now im thinking that what I did was unecessary - adding extra crap to an already
convoluted system.

So, if you have extra cycles, I suggest you attack the tree and clean all of
these up and make them consistent.  Just hardcode the SOMETHING to "moz" as you
did with your last libreg change.

Bonus points for doing the same on windows.  The windows weenies dont really
care about this, so making it consistent with unix would be good for the benefit
of the folks that have to deal with both worlds.

thanks.

Comment 11

[Daniel Veditz [:dveditz]]

Ramiro's suggestion is fine, but drop the "lib" part -- .dll names MUST remain
8.3 or the install will not be able to upgrade them on Win9x (I've filed bugs
on the ones that aren't)

Comment 12

[Brian Ostrom]

The Unix portion of this is now fixed.  I will deal with the equivalent
change for Windows after M9, because it looks more complicated and more
convoluted and I will probably screw it up the first time.  Ramiro's
suggestion will be simple, so I'll see if I can sneak it in before M9.

Comment 13

[Brian Ostrom]

Okay, the hardcoding of the MOZ_LIB_whatever_PREFIX references are
done and checked in.  All that's left to do (later) is the equivalent
set of changes for Windoze.

Comment 14

[ramiro]

Thanks.  That simplifies stuff some.

Comment 15

[Brian Ostrom]

Looks like someone already took care of this for me on the Windows
side.  Closing the bug.