[GitHub] [openoffice] ardovm commented on pull request #174: Remove use of pthread_mutexattr_setkind_np due to compile errors
ardovm commented on PR #174: URL: https://github.com/apache/openoffice/pull/174#issuecomment-1464871841 Thank you for you report! > This is intended as an informative notification, since I have no idea how to actually create a bugzilla account. You could follow the instructions at https://bz.apache.org/ooo/createaccount.cgi or write to the [dev list](https://openoffice.apache.org/mailing-lists.html#development-mailing-list-public) asking for help. > The code being removed here causes a compilation issue on Ubuntu Jammy Jellyfish. (undefined reference to `pthread_mutexattr_setkind_np`) The best I can tell, https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2003146 explains this somewhat. Using `nm` as described on that report, we can demonstrate that symbol `pthread_mutexattr_setkind_np` _is_ still present on other current mainstream distributions: ``` $ lsb_release -d ; nm /usr/lib/x86_64-linux-gnu/libpthread.so.0 | grep pthread_mutexattr_getkind_np Description:Debian GNU/Linux 11 (bullseye) ca30 W pthread_mutexattr_getkind_np ``` and ``` $ lsb_release -d ; nm /usr/lib64/libpthread.so | grep pthread_mutexattr_getkind_np Description:openSUSE Leap 15.4 f5de W pthread_mutexattr_getkind_np ``` On the other hand, applying your patch to AOO41X makes it not compile any more on our (admittedly outdated) Linux reference build systems. (I know you are proposing a patch to trunk, but IMHO it may be worth to look at the bigger picture, if we can) > This workaround likely hasn't been necessary for the past 20 years, if glibc "converted to git" repositories are any indication (see for instance https://github.com/lattera/glibc/blob/d82e4c7bb231c9e0f835bd46467563ac3b56cebe/linuxthreads/sysdeps/pthread/pthread.h ). As explained above, your problems seems to be Ubuntu-specific, at least for now. IMHO we should look for other ways (like `#ifdefs`) to allow compilation on both systems with and without the deprecated symbol. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] 20kdc commented on pull request #174: Remove use of pthread_mutexattr_setkind_np due to compile errors
20kdc commented on PR #174: URL: https://github.com/apache/openoffice/pull/174#issuecomment-1464885826 I've modified the commit to test for the presence of `PTHREAD_MUTEX_RECURSIVE_NP` instead of removing the code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fwd: E-mail address for publishing extensions is wrong
Hi All,
The extension site gets more and more broken...
I don't have the time to spend hours on every new extension that someone
wants to publish.
Maybe we should get the problems fixed?
Regards,
Matthias
Am 09.03.23 um 17:46 schrieb Matthias Seidel:
>
> Hello All,
>
> FYI:
>
> While I can publish the extension page, the downloadable files are
> (again) not to be found in the SourceForge database.
>
> Apart from that, we need a working mail address for users to contact us.
>
> Regards,
>
> Matthias
>
>
> Weitergeleitete Nachricht
> Betreff: E-mail address for publishing extensions is wrong
> Datum:Thu, 9 Mar 2023 17:24:20 +0100
> Von: Bogdan
> Antwort an: us...@openoffice.apache.org
> An: us...@openoffice.apache.org
>
>
>
> Hello.
>
> After I created my extension, I wanted to publish it, but instead I
> saw the message:
>
> "
> This extension is currently not published. Please contact the system
> administrator at nore...@extensions.openoffice.org to have it
> published, including a link to this page.
> "
>
> What would be the actual address to write to? Because it isn't
> "noreply", right?
>
> The extension is:
> https://extensions.openoffice.org/en/project/keyparastocx
>
> Thank you!
>
> --
> Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
> X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
> Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
> www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: users-h...@openoffice.apache.org
>
smime.p7s
Description: S/MIME Cryptographic Signature
Re: GNU make 4.4 under Cygwin64
Hello Matthias, All, apparently, compatibility with the latest GNU Make is not yet ensured. On Tue, Dec 06, 2022 at 01:20:17PM +0100, Matthias Seidel wrote: > And in the end it doesn't build: > > --- > > = > Building module slideshow > = > > Entering /cygdrive/c/Source/openoffice/main/slideshow/prj > > cd .. && make -s -r -j1 && make -s -r deliverlog > [ build CXX ] slideshow/source/engine/slideshowimpl > slideshowimpl.cxx > c:/Source/openoffice/main/slideshow/source/engine/slideshowimpl.cxx(25) > : fatal error C1083: Cannot open include file: > 'precompiled_slideshow.hxx': No such file or directory > make: *** No rule to make target > '/cygdrive/c/Source/openoffice/main/solver/420/wntmsci12.pro/workdir/CxxObject/slideshow/source/engine/slideshowimpl.o', > needed by > '/cygdrive/c/Source/openoffice/main/solver/420/wntmsci12.pro/workdir/LinkTarget/StaticLibrary/sldshw_s.lib'. > > Stop. > dmake: Error code 2, while making 'all' [...] This seems to be a different problem than addressed with PR #175. The slideshow module seems to fail because the slideshowimpl.cxx file is not provided the correct include path. There are two Makefiles, inside module slideshow, where the slideshowimpl "object" is listed: - StaticLibrary_sldshw_s.mk: that contains the proper build parameters passed to: * gb_StaticLibrary_add_api, * gb_StaticLibrary_set_include. - Library_slideshow.mk that does not list any of the above. If I add to the second file the calls to gb_Library_add_api and gb_Library_set_include, with the same parameters as the static library counterparts, then the compilation seems to be successful. If the above is not clear, I can open a PR proposing the above edits. But the question is: why is the same "object" "slideshowimpl" listed in two files? The second has a comment stating: # List this file again, even though it's in the static lib, so that # component_getFactory and component_getImplementationEnvironment are exported: This seems to be broken now, with the latest GNU Make. I hope this makes sense. Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
FreeBSD port status
I've had some time in the last couple of weeks to work on the FreeBSD port. I was able to get 4.1.14 to build and updated the FreeBSD port to that version. I committed the upgrade to the main branch of the FreeBSD ports tree on March 8. I merged the change to the current ports quarterly branch a short while ago, so mainstream users should see the new binary packages show up in the next several days. For various reasons, I switched the FreeBSD port back to the bundled boost. The FreeBSD port uses -std=gnu++98 mode to compile our code. One of the things I found is that even in that mode, our bundled boost tries to use some c++11 features, and recent versions of clang treat that as an error. This can be fixed with a trivial patch, which I added to the FreeBSD port. I plan to commit this fix to our source tree in the near future. Another FreeBSD user found that our build is fragile, and can be broken if the build environment is not clean. The problem is that the order of the directories in our include path is not safe. We put the include directories for external dependencies like the libs for gtk ahead of internal and solver directories. If one of the system include directories is /usr/local/include, then the build can pick up the system boost if it is installed on the machine. The FreeBSD boost port has issues with gnu++98 mode. This breaks both gbuild and dmake module builds of 4.1.x. Gbuild is mostly fixed in trunk and 4.2.x, and on those branches so much has been converted to gbuild that I haven't seen the problem. The modules left using dmake don't seem to both use boost and have problematic external dependencies. I have patches for both the gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD platform. The dmake framework patch is generic, but I've only tested it on FreeBSD. The FreeBSD port broke some time ago because of errors in some of the API comments in the xmerge java source. We've fixed these in trunk and 4.2.x, but they are still broken in 4.1.x. They have been flagged as errors during the build for a very long time, but it was only sometime last summer when they started getting treated as a fatal error by the FreeBSD build. They are still flagged as errors, but they are no longer fatal. I have no idea what caused the behavior to change in either direction. I also experimented a bit with c++11 mode and discovered that recent versions of clang are much less forgiving of questionable code in that mode as compared to the older versions of clang that I tried several years ago. I ran into many things that broke the build: reinterpret_cast< some_type*>(NULL) is a compilation error. These are trivial to fix by switching to static_cast, but the modules where these occur seem to use reinterpret_cast excessively. I would be surpised if there were more than a handful of locations in our code where reinterpret_cast is the right choice. Constructors where the width of the initialization data is wider than the width of the member being initialized break the build. Recent clang does not want to automatically narrow the data and wants an explicit cast to be used. The casts are easy to add, but the compiler is pointing out places in the code where there might be exploitable integer overflows. Perhaps the member should be widened so that an overflow isn't possible, or pehaps an assert should be added or an exception thrown on overflow. The canvas, dbaccess, reportdesign, and slideshow modules use iterators such a ::std::find_if and ::std::count_if to repeatedly call functions using ::boost::bind whose args are all supposed to be references. In some instances the code uses ::boost::cref() to convert expressions into references. Recent clang objects if the argument to ::boost::cref() is not an lvalue. A handful are trivivally fixable, but most are not. In some cases it is not obvious if the value of the expression shouldn't be changing due to the actions of the function in the previous iteration, so calculating the expression once, storing the result in a temporary location and passing a reference to that location could result in stale data being used. In another case, a method is called that constructs a struct and fills it with a bunch of data from multiple class member values, and the struct is returned, a reference to that struct is created and that reference passed to the function. It isn't obvious to me that some of those class members are not modified by the function, so the stale data issue is there, but also the memory for the struct is leaked because it is never destroyed. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
