[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Wed May 31 23:42:41 -0700 2006 --- *** Issue 65545 has been marked as a duplicate of this issue. *** - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Wed May 3 02:56:20 -0700 2006 --- Well, this is getting a bit out of hand, but I'll bite. It does not have to come with the OS, but it is always built for the particular OS. It is better to require certain libraries/packages to be installed, than to provide your own versions of them all. This is also known as DLL hell. Sorry, there is no way that we can build versions for the zillions of Linux distributions, two major and a number of minor versions of Windows and three major (with about a dozen of minor updates) Solaris versions (both x86 and sparc). But we don't let the customer stand in the rain. His copy of SO/OOo will work on any reasonable system. DLL hell is if you require your user to figure out all the dependencies. Oh, don't mind that he might have a need for a application which needs version x off library foo and another that needs y and the maintainer of foo made a little error in backward compatibility. As long as you keep your copy of libraries separate, there is only some wasted disk space, a resource which is not scarce nowadays. OOo would save itself A LOT of work if it stopped trying to maintain the 3rd-party chunks of the tree, and concentrated instead on the core OOo software. It would also reduce the distribution tarballs and cut the build times. You are seriously in error here. As I said before, streamlining 3rd party stuff is possible (and is done) for those who target certain distributions, but not for the general version. The general version can only take from the system which is there with absolute certainty (the precompiled version) or for the source version, which can be reasonably be expected from a developer system. An example is PAM. The effort of maintaining, say, a frozen version of icu in our tree is far below than that we would have to bear if we used the system version which might be not existant on an old system or might be broken (because to old) etc. And don't talk about the test matrix. Using our current approach we can be reasonably sure, that, if we test it on a number of new and old systems, it will work on any odd distribution. By building *everything* from scratch, you are either duplicating (often poorly) or even defeating the work of the system integrators, because the superior streamlined versions are not built routinely and bit-rot occurs. Caolan and others did magnificient work to support the streamlined versions, but we simply need both. And don't tell to me about bit rot. Our old versions still work on new systems. When was the last time you tried something like this with - say - gnome? I don't claim there is not any 3rd party component which we could do better without. STLport is a good example. It was introduced when there was no way to do STL development with the sorry excuses of STLs which were shipped with the compilers. This certainly has changed and I wouldn't mind getting rid of STLport. This involves binary compatibility issues, and it involves getting things like hash_map, slist and rope working on Windows, which has an implementation which is not SGI derived. Some work but not impossible. But if someone does it, she/he has to do it for every platform which is supported, not just her/his favourite platform. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 User hr changed the following: What|Old value |New value Status|NEW |RESOLVED Resolution| |FIXED --- Additional comments from [EMAIL PROTECTED] Wed May 3 10:00:58 -0700 2006 --- The clean up part of the patch has been applied to CWS hr33. I've left out the hasher changes and the bvector changes, AFAIK they are not necessary with Caoloans wrapper approach.. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 User hr changed the following: What|Old value |New value Target milestone|DevTools |OOo 2.0.4 --- Additional comments from [EMAIL PROTECTED] Wed May 3 10:18:42 -0700 2006 --- set target milestone to OOo-2.0.4 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue May 2 07:41:26 -0700 2006 --- @panbk,cmc: What do we do with this patches? I do not like the renaming scheme, I find Caolans approach better. Does FreeBSD nowadays compile with --with-system-stl? Tiding up unused headers is always a good thing though. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue May 2 07:59:20 -0700 2006 --- hr, how FreeBSD *is* building OOo is not as important as how it *should be* doing it :-) Generally, I think, no OS should rebuild OOo's STLport if it already has a compatible implementation. And when it does not, I'd rather OOo had it as a pre-build requirement, than built its own. This applies to all 3rd-party packages currently shipped with OOo. IMO, it is a big folly to bundle things like expat, python, graphics libraries, et al. instead of simply saying, they must be installed already. They are easy to install on a good OS, and users of a bad one will not be building OOo from source anyway. As you may read from this discussion, I tried removing the OOo's stlport directory from the tree prior to build, to ensure, that *nothing* from there will make its way into the compiled programs. If cmc's patches use that directory to force the system STLport -- fine, although I'd prefer direct use of the external STLport (either compiler's own, or the official one from SGI). My concern was the bit-rot... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue May 2 08:33:19 -0700 2006 --- @panbk: Always using what can be found on the system is nice if you think of OOo as something which is always build and distributed together with an OS. But there are more ways to distribute OOo than this. The versions compiled by Hamburg RE run on any current Linux x86 systems regardless if they bundle certain libs or not. The only requirement is glibc-2.2.4 or newer (shipped for instance with the stone old SuSE 7.3 systems). Solaris versions run on Solaris 8 and later. Windows even runs on Windows 98 SE, I think. The customer really doesn't have to think about if his OS has all depencies fullfilled, it just works. And this is how it should be. Add to this certain binary compatibility requirements, you don't really want to shut out 3rd party vendors of components on the whim. Of course, distributors like RedHat and Novell, the FreeBSD port teams etc like to have streamlined versions of OOo wich uses any system shared lib which is already bundled the OS. Valid request, and so we support both approaches at the expense of having a slightly lager repository - but that's not something the customer will see ... So I would suggest Caolans approach. On the other hand tidying up unused STL header inclusions is always a good thing, can you extract them from the patch? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue May 2 14:10:17 -0700 2006 --- Always using what can be found on the system is nice if you think of OOo as something which is always build and distributed together with an OS. It does not have to come with the OS, but it is always built for the particular OS. It is better to require certain libraries/packages to be installed, than to provide your own versions of them all. This is also known as DLL hell. OOo would save itself A LOT of work if it stopped trying to maintain the 3rd-party chunks of the tree, and concentrated instead on the core OOo software. It would also reduce the distribution tarballs and cut the build times. By building *everything* from scratch, you are either duplicating (often poorly) or even defeating the work of the system integrators, because the superior streamlined versions are not built routinely and bit-rot occurs. On the other hand tidying up unused STL header inclusions is always a good thing, can you extract them from the patch? The patch largely consists of just that. The renaming work is done by the script. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 User mh changed the following: What|Old value |New value Assigned to|mh|hr Ever confirmed| |1 Status|UNCONFIRMED |NEW Target milestone|--- |DevTools --- Additional comments from [EMAIL PROTECTED] Mon Feb 6 05:09:32 -0800 2006 --- reassign - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue Nov 1 01:40:31 -0800 2005 --- panbk: Please, do I get it right that you are changing std:: namespace to __gnu_cxx::? I don't think it is a good idea - what about the other compilers than gcc - e.g. on Windows? Or do I miss something here, please? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue Nov 1 05:40:22 -0800 2005 --- Well, yes, that is, what I'm doing -- for classes, which are only available in the __gnu_cxx:: namespace. But, of course, I only do this, when compiling with GNU C++. This is why the change is split between a patch (which can be used with any compiler) and a script (which only has to run, when using GNU C++). The patch removes unneeded #include-s (including from mdbtools) and renames a few items, to ease the job of the script (i.e. hash - hasher). The reason OOo does not notice a problem, is because stlport headers are included at compile time, even when configured to build without stlport. If you _remove_ the stlport sub-directory prior to building, the problems I'm trying to solve will pop up. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue Nov 1 05:54:59 -0800 2005 --- Hmm, I see; but still this does not sound to me like the right thing for long-term... Why don't you want to use stlport? Does it have problems on FreeBSD? Wouldn't it be better to fix stlport then? The goal of porting is to be able to compile OOo on the target platform without modifications - like when one runs ./configure on FreeBSD/amd64, bootstrap dmake, and gets a working OOo - but it must not break the other platforms. And also, all this should be possible without running an additional script that modifies the sources. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue Nov 1 06:04:37 -0800 2005 --- 1) I'd like to avoid using STLport because it is an extra dependency -- and a large one. Also, in at least one location (see my patch), an inferior method (hashmap instead of map) was picked by the developer _to avoid linking with stlport_. 2) There is already an option in configure to build `--without-stlport4'. The advice _against_ using this option is that it breaks ABI compatibility. This does not bother a FreeBSD in general and a non-i386 FreeBSD user in particular :-) All of the functionality found in STLport is also found in modern versions of compilers, so why not use it? My script (or some derivative of it) can run in boostrap. I'm also seeing attempts to solve this problem by #define-ing the namespace name (::std or __gcc_cxx::) based on configure results. Maybe, my script can be used to _once_ find all instances, where this #define needs to be used. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue Nov 1 08:38:24 -0800 2005 --- This should already be possible by using --without-stlport4, and the cunning hackery I have in stlport for mapping system stl into the std namespace. All without requiring any other changes in the rest of the source. But see gcc bugzilla 19664 for a hideous got-ya with using system stl and gcc visibility. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue Nov 1 09:41:54 -0800 2005 --- Well, using --without-stlport4 was not enough with the 2.0RC3, so I devised my own renaming script. I'll try building without it again, but I did not see the -I/usr/include/c++/3.4/ext among the CFLAGS, so I doubt, that lines like '#include hashmap' will work. They, probably, work for you, because you do not remove the stlport subtree from your build tree. You should :-) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Tue Nov 1 11:53:09 -0800 2005 --- Some tweaking might be required with the approach as its not generally in use seeing as I don't use it due to the gcc visibility and stl problem, and so may have gone a little stale. But in the stlport makefile.mk see the SYSTEM_STL conditional path which causes the contents of the systemstl dir e.g. hashmap to be copied into the stlport solver where deliver will then put them into the OOo solver in locations where #include hashmap will find this copied file, and that file has then e.g. e.g. #include ext/hash_map and the namespace foo required to pull the __gnu_cxx bits into the std namespace. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 User panbk changed the following: What|Old value |New value Attachment data| |Created an attachment | |(id=30866) Updated version | |of automatic renamer. Some | |kludges added to avoid | |renaming, what need not be --- Additional comments from [EMAIL PROTECTED] Wed Oct 26 07:49:18 -0700 2005 --- Created an attachment (id=30866) Updated version of automatic renamer. Some kludges added to avoid renaming, what need not be - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 User panbk changed the following: What|Old value |New value Attachment is patch| |Created an attachment | |(id=30867) Some more | |patching away of unneeded | |include-s, etc. --- Additional comments from [EMAIL PROTECTED] Wed Oct 26 07:50:43 -0700 2005 --- Created an attachment (id=30867) Some more patching away of unneeded include-s, etc. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 --- Additional comments from [EMAIL PROTECTED] Wed Oct 26 07:53:16 -0700 2005 --- Kendy! One of the hunks I just attached patches the new connectivity/source/drivers/mdb/mdb_wrapper.hxx you have. Can you, please, take a look? It is rather trivial... Thanks! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 User panbk changed the following: What|Old value |New value Attachment is patch| |Created an attachment | |(id=30418) Fix a few STL- | |using files --- Additional comments from [EMAIL PROTECTED] Thu Oct 13 20:33:29 -0700 2005 --- Created an attachment (id=30418) Fix a few STL-using files - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[porting-issues] [Issue 55967] Using GCC's STL is not re ally possible without this
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967 User panbk changed the following: What|Old value |New value Attachment data| |Created an attachment | |(id=30419) Change all | |other files to use GCC's | |implementation of certain | |STL constructs --- Additional comments from [EMAIL PROTECTED] Thu Oct 13 20:34:49 -0700 2005 --- Created an attachment (id=30419) Change all other files to use GCC's implementation of certain STL constructs - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
