Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Francois, On Tue, 31 May 2011 23:33:06 +0200 Francois Tigeot ftig...@wolfpond.org wrote: What you said about the gbuild migration makes sense, but I have the impression you were thinking about removing completely the suffix. [...] The final library name would be the same, it would not be problematic to remove DLLPOSTFIX a little bit at a time. what I meant was when you change at: http://opengrok.libreoffice.org/xref/bootstrap/solenv/gbuild/platform/linux-INTEL.mk#32 gb_Library_DLLPOSTFIX := li to gb_Library_DLLPOSTFIX := lo gbuild will with this one change rename all gbuild libraries from libfooli.so to libfoolo.so on Linux Intel. And it will assume all libraries build by the old build system to also be named libbarlo.so instead of libbarli.so. So if library bar is build by the old build system and library foo by the new one but links against bar, they would need to be renamed at the same time. Given the stuff in tail_build links against pretty much everything, doing that you would not make you change a little bit at a time, but in one big move -- at least for a given platform. I also consider that a not a Bad Thing(tm) given the stuff I said about this causing lots of rebuilds. But you will find that out yourself when you start working on this, I guess. ;) Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Bjoern, On Sun, May 29, 2011 at 09:19:30PM +0200, Bjoern Michaelsen wrote: On Sun, 29 May 2011 20:41:20 +0200 Francois Tigeot ftig...@wolfpond.org wrote: One of your links is about a change of API but there would be none. The consensus seemed to be this DLL suffix stuff was absolutely unused and useless. If you leave the UNO standard libraries alone, feel free to go for it. But you did not say that It was my understanding the UNO libraries didn't use DLLPOSTFIX but now you're making me doubt. Is there a canonical list of them I could check ? -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Tue, 2011-05-31 at 08:10 +0200, Francois Tigeot wrote: Is there a canonical list of them I could check ? In an install set these should be in /path/to/libreoffice/ure/lib and/or dig around for SCP2_URE_foo in scp2 C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Tue, 2011-05-31 at 08:10 +0200, Francois Tigeot wrote: It was my understanding the UNO libraries didn't use DLLPOSTFIX but now you're making me doubt. They do not :-) Is there a canonical list of them I could check ? ls ure/lib # in an install ;-) ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Tue, 31 May 2011 08:10:13 +0200 Francois Tigeot ftig...@wolfpond.org wrote: Hi Bjoern, It was my understanding the UNO libraries didn't use DLLPOSTFIX but now you're making me doubt. Is there a canonical list of them I could check ? As Michael and Caolan already said, no problem there, go for it! Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
If it is not about those, I dont object, although I do not see to much use in it (I would have waited for the 4 API and changed all names -- including the API ones -- then). I mostly agree with Björn here. In my opinion the reason to drop DLLPOSTFIX would be to make the makefiles clearer. Not so much to make the library names more readable. So if we keep DLLPOSTFIX, just unify its value on all platforms, that doesn't really affect the complexity of the makefiles at all. We just lose one non-conditional simple assignment line from each platform-specific .mk file. (Not that the use of $(DLLPOSTFIX) is a major uglifying factor in the makefiles; but any simplification helps.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Mon, May 30, 2011 at 12:32:48AM -0600, Tor Lillqvist wrote: So if we keep DLLPOSTFIX, just unify its value on all platforms, that doesn't really affect the complexity of the makefiles at all. We just lose one non-conditional simple assignment line from each platform-specific .mk file. (Not that the use of $(DLLPOSTFIX) is a major uglifying factor in the makefiles; but any simplification helps.) This is what I wanted to do as a first step, sorry if I wasn't clear enough. Let me restate the plan so far: 1. Unify DLLPOSTFIX values. Set it in one common .mk if possible This can be done now 2. Remove DLLPOSTFIX usage in the build system This can be done bit by bit There is no fundamental reason to keep it for 4.0 but it can well be left as-is until then. -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Francois, On Mon, 30 May 2011 09:40:27 +0200 Francois Tigeot ftig...@wolfpond.org wrote: 1. Unify DLLPOSTFIX values. Set it in one common .mk if possible This can be done now Yes, as long as you are only talking about the li, lx, ss, si type postfixes of applications and indeed no UNO library accidentally uses those prefixes too. The gcc3-style postfixes certainly are used for UNO libs. 2. Remove DLLPOSTFIX usage in the build system This can be done bit by bit There is no fundamental reason to keep it for 4.0 but it can well be left as-is until then. At least for gbuild there is a fundamental reason: The gcc3-style postfixes, the .uno.so, the li/lx-style postfixes and others are all provided over the same mechanic. I would be a simplification to get rid of all of those (and even more importantly the special cases like comphelper who are not even sticking to _any_ of the plethora of naming schemes). Just renaming the DLLPOSTFIX is indeed a most trivial, atomic change in gbuild: http://opengrok.libreoffice.org/search?q=gb_Library_DLLPOSTFIXproject=bootstrap Change that and all are renamed. Thus, in gbuild it cant be done bit-by-bit as it is just one change. However, you will have quite a bit more work in the old build system (which you will also have to do in one big change as library names are used in both build systems -- you cant just change those in one build system). Another reason why bit-by-bit is a bad idea: Even if you would rename a single lib at a time (*), each such change would lead to major rebuild on master for everyone, which should be avoided. Which is why I would have rather have more stuff migrated to gbuild (which needs to be done anyway) and do the trivial change there, rather than investing work in the old build system, just to throw it away with the gbuild migration anyway. Best, Bjoern (*) Which in theory could also be done by making yourself even more additional work, by first renaming them manually one-by-one hard in RepositoryFixes.mk. -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Mon, 2011-05-30 at 10:18 +0200, Bjoern Michaelsen wrote: Yes, as long as you are only talking about the li, lx, ss, si type postfixes of applications and indeed no UNO library accidentally uses those prefixes too. The gcc3-style postfixes certainly are used for UNO libs. So it seems we are agreed that this is fine - as long as it is a single, big atomic commit that does it for every library :-) So - go go go ! :-) Thanks Francois, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Sun, 2011-05-29 at 18:56 +0200, Francois Tigeot wrote: On Tue, May 24, 2011 at 11:26:30AM +0100, Caolán McNamara wrote: Different DLLPOSTFIX files suggest that at some stage or other it was desirable to be able to have the .sos from different architecture side-by-side in the same dir. Maybe from an era before the separate arch dirs in the solver dir, dunno. I vaguely remember someone mentionning a giant file server in Hamburg where all binaries where stashed together ... As an aside, binary extensions can have multiple architectures in them, but I don't think the per-arch suffixes we use for the internal libFoos are propagated into the sdk for this purpose, a different arch identifier is used IIRC. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Tue, May 24, 2011 at 11:26:30AM +0100, Caolán McNamara wrote:
IMO, a consistent DLLPOSTFIX name is probably better than removing it
totally, to avoid e.g. something like libCOMMONNAME${DLLPOSTFIX}.so
becoming libCOMMONNAME${DLLPOSTFIX}.so colliding painfully with some
common system lib like libCOMMON.so when linking or with the effectively
non-hierarchal flat rpm autorequires/provides.
After a few days of idle meditation, I tend to agree with this position:
even though the DLLPOSTFIX character string has no useful purpose, it
would be best to ensure the libraries keep unique names, different from
system or third-party packages ones.
I'd like to use 'lo' as a common platform suffix.
In a first stage, the build system would still be using DLLPOSTFIX as-is,
only with a unique value.
In a second stage, the suffix would be directly integrated to the library
names, and could be kept or removed on a case-by-case basis.
If there is no objection, I intend to begin the work in a few days.
Different DLLPOSTFIX files suggest that at some stage or other it was
desirable to be able to have the .sos from different architecture
side-by-side in the same dir. Maybe from an era before the separate arch
dirs in the solver dir, dunno.
I vaguely remember someone mentionning a giant file server in Hamburg where
all binaries where stashed together ...
--
Francois Tigeot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Francois, On Sun, 29 May 2011 18:56:46 +0200 Francois Tigeot ftig...@wolfpond.org wrote: In a first stage, the build system would still be using DLLPOSTFIX as-is, only with a unique value. That would still be a change for LibreOffice4 ... If there is no objection, I intend to begin the work in a few days. ... which is why I object. I vaguely remember someone mentionning a giant file server in Hamburg where all binaries where stashed together ... I do not. If such things happened, it was in ancient times. see: http://wiki.documentfoundation.org/Development/LibreOffice4 http://sweetshark.livejournal.com/1550.html Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Just to clarify: On Sun, 29 May 2011 20:27:53 +0200 Bjoern Michaelsen bjoern.michael...@canonical.com wrote: That would still be a change for LibreOffice4 ... (if we also change UNO API libs) If there is no objection, I intend to begin the work in a few days. ... which is why I object. (in that case). If it is not about those, I dont object, although I do not see to much use in it (I would have waited for the 4 API and changed all names -- including the API ones -- then). Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
On Sun, 2011-05-22 at 11:43 -0600, Tor Lillqvist wrote:
What I would like to know is if there's still a reason to use this suffix
in 2011.
Only backward compatibility of binary extensions
Extensions aren't supposed to link (or be able to link) against
DLLPOSTFIX libs AFAIR, they're only supposed to be able to directly link
against the ure libs that start (under Unix) with lib. Those are
conveniently installed in /path/to/install/ure/lib for perusal, and
there are no uses of DLLPOSTFIX in there.
One gotcha is that tools/inc/tools/solar.h needs to be tweaked, etc. for
any dlopen stuff that libreoffice does. IIRC if you cock this up, it may
appear to work up until you attempt to open one of factory dialogs
e.g. format-character in calc and then it'll fail. Lazy uno porting
guide points out any gotchas like that.
IMO, a consistent DLLPOSTFIX name is probably better than removing it
totally, to avoid e.g. something like libCOMMONNAME${DLLPOSTFIX}.so
becoming libCOMMONNAME${DLLPOSTFIX}.so colliding painfully with some
common system lib like libCOMMON.so when linking or with the effectively
non-hierarchal flat rpm autorequires/provides.
Different DLLPOSTFIX files suggest that at some stage or other it was
desirable to be able to have the .sos from different architecture
side-by-side in the same dir. Maybe from an era before the separate arch
dirs in the solver dir, dunno.
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Francois, If we are talking about the 'li' suffix in libswli.so - then I don't see much good reason for that really. On Sun, 2011-05-22 at 20:03 +0200, Francois Tigeot wrote: Where can I find more about this ? I've found some openoffice.org web pages about extensions but nothing really useful about UNO and the C++ extension ABI. Presumably extensions use only the standard, stable UNO APIs - and none of them use fooli.so etc. tried to make it easy to switch of the creative naming in the new build system at once. Which leads us to the next point: Doing the switch while we still have two build systems is not a good idea. Ok. Three of the *BSD systems (OpenBSD, DragonFly, NetBSD) have already had their DLL suffixes unified in a single one per OS. Or did I miss the point ? :-) but anyhow, we have a wiki page for things we know may be painful for extension authors - so we can do them all at once for 4.0: http://wiki.documentfoundation.org/Development/LibreOffice4 Perhaps add it there if you can't get immediate satisfaction :-) ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Michael, On Mon, May 23, 2011 at 04:49:58PM +0100, Michael Meeks wrote: If we are talking about the 'li' suffix in libswli.so - then I don't see much good reason for that really. Presumably extensions use only the standard, stable UNO APIs - and none of them use fooli.so etc. I'm thinking the same thing: I only downloaded a few ones, but so far none of them made use of the suffixed libraries. Or did I miss the point ? :-) but anyhow, we have a wiki page for things we know may be painful for extension authors - so we can do them all at once for 4.0: http://wiki.documentfoundation.org/Development/LibreOffice4 Perhaps add it there if you can't get immediate satisfaction :-) I've added an item about DLLPOSTFIX, and I already have the satisfaction to know it's a completely useless feature ;-) Here's a list of all the different suffixes so far: (thats an empty one) ap ar df fi fx gi l3 la lh li ll lm lp lr ls lx mi mx mxi mxp nb ob si sogi sogs ss su The empty one is from unxiosr.mk and I suspect the platform doesn't build because of this. If removing the suffix is too much work for 3.5, what about using the same one for all platforms ? Say, we could use dll and have the same libfoodll.so file name everywhere (minus the extension) This would at least ease the packaging for people having to manage different platforms. -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
The empty one is from unxiosr.mk and I suspect the platform doesn't build Indeed not, unxiosr is the just started extremely unfinished partial port to iOS ;) Far from ready, if it ever will be. Shared libraries / dynamic modules can't even be used for non-system code on iOS so no DLL suffix is needed. (Yeah, how UNO would / will work if everything is statically linked remains to be tinkered/experimented with.) If removing the suffix is too much work for 3.5, Nah, why would it be that much work? If it is agreed that those shared libraries that use those suffixes are ones that binary extensions don't link to anyway, let's just do it. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Platform-specific DLL suffix usefulness
Hi, I've recently created a pkgsrc package for LibreOffice, and been burned by the DLLPOSTFIX / gb_Library_DLLPOSTFIX suffix added to library file names. I'm sure there was a good reason to use it in 1988. Or maybe not, I can't possibly pretend to know. What I would like to know is if there's still a reason to use this suffix in 2011. It would tremendously simplify packaging to use the same file names on all platforms. I currently have to find a way to extract the suffix from the build configuration or recreate it in my packaging scripts and use it to create the file list, which is a bit of a maintainability nightmare to say the least... Any thoughts on this subject ? -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Francois, On Sun, 22 May 2011 18:45:53 +0200 Francois Tigeot ftig...@wolfpond.org wrote: I'm sure there was a good reason to use it in 1988. Or maybe not, I can't possibly pretend to know. Probably not. I'd rather guess it was a workaround to a problem that would have deserved a proper solution back then. What I would like to know is if there's still a reason to use this suffix in 2011. Unfortunately, yes: compatibility for C++ extensions -- at least for the lower level libs that provide most of the UNO infrastructure. It would tremendously simplify packaging to use the same file names on all platforms. Thats why it is already on http://wiki.documentfoundation.org/Development/LibreOffice4, and why I tried to make it easy to switch of the creative naming in the new build system at once. Which leads us to the next point: Doing the switch while we still have two build systems is not a good idea. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
What I would like to know is if there's still a reason to use this suffix in 2011. Only backward compatibility of binary extensions, I think? But how many of the OOo/LO shared libraries do (binary) extensions link to anyway? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Bjoern, On Sun, May 22, 2011 at 07:36:27PM +0200, Bjoern Michaelsen wrote: On Sun, 22 May 2011 18:45:53 +0200 Francois Tigeot ftig...@wolfpond.org wrote: What I would like to know is if there's still a reason to use this suffix in 2011. Unfortunately, yes: compatibility for C++ extensions -- at least for the lower level libs that provide most of the UNO infrastructure. Where can I find more about this ? I've found some openoffice.org web pages about extensions but nothing really useful about UNO and the C++ extension ABI. It would tremendously simplify packaging to use the same file names on all platforms. Thats why it is already on http://wiki.documentfoundation.org/Development/LibreOffice4, and why I You're sure ? I do not see anything explicit about file names / platform suffixes. tried to make it easy to switch of the creative naming in the new build system at once. Which leads us to the next point: Doing the switch while we still have two build systems is not a good idea. Ok. Three of the *BSD systems (OpenBSD, DragonFly, NetBSD) have already had their DLL suffixes unified in a single one per OS. Could it negatively impact something barring possible C++ binary extensions ? -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific DLL suffix usefulness
Hi Tor, On Sun, May 22, 2011 at 11:43:52AM -0600, Tor Lillqvist wrote: What I would like to know is if there's still a reason to use this suffix in 2011. Only backward compatibility of binary extensions, I think? But how many of the OOo/LO shared libraries do (binary) extensions link to anyway? And how do they do it ? I've downloaded an extension from http://extensions.services.openoffice.org/ and the included binaries are ELF objects but they do not need libraries with special platform suffixes. [objdump -x extract] Dynamic Section: NEEDED libcrypt.so.1 NEEDED libnsl.so.1 NEEDED libuno_cppu.so.3 NEEDED libuno_sal.so.3 NEEDED libuno_salhelpergcc3.so.3 NEEDED libuno_cppuhelpergcc3.so.3 NEEDED libstlport_gcc.so NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
