Closed Bug 8568 Opened 22 years ago Closed 22 years ago
Unix: library name collosions
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 :-(
I could make this simple change, but Dan is the right person to do it.
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?
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*.
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.
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.
too close to milestone to do mass library renaming. pushing to M9
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.
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?
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.
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.
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)
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.
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.
Thanks. That simplifies stuff some.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Looks like someone already took care of this for me on the Windows side. Closing the bug.
You need to log in before you can comment on or make changes to this bug.