On 2025-07-24 10:14, Lodev wrote:
Yes, we just found out that using --with-system-jpeg would succeed
compiling. So our task could move on.
Good to hear you can at least avoid the problem for now.
Just that, does it mean there is something wrong within the master code,
or the dependencies it
Hi Michael,
Michael Weghorn 於 2025/7/24 11:53 寫道:
On 2025-07-23 07:24, Lodev wrote:
We experienced some errors when compiling LibreOffice core (master).
We pulled the latest code from master branch. Running ./autogen.sh
with-distro=LibreOfficeLinux --disable-online-update --disable-breakpad
On 2025-07-23 07:24, Lodev wrote:
We experienced some errors when compiling LibreOffice core (master).
We pulled the latest code from master branch. Running ./autogen.sh
with-distro=LibreOfficeLinux --disable-online-update --disable-breakpad
Until this error messages:
[...]
(.text._ZN7fxco
Hi,
We experienced some errors when compiling LibreOffice core (master).
We pulled the latest code from master branch. Running ./autogen.sh
with-distro=LibreOfficeLinux --disable-online-update --disable-breakpad
Until this error messages:
[build MOD] sal
/usr/bin/ld: /tmp/lto-llvm-4818d7.
Hi Mike, hi Julian,
I am comforted to know that I am not the only one affected by such problems.
Julien Nabet schrieb am 29.01.2023 um 09:58:
Indeed, the rare case when I build LO on Windows, first time is ok
because I start with a "make clean", update Visual Studio, Windows,
Cygwin, ... but o
Indeed, the rare case when I build LO on Windows, first time is ok
because I start with a "make clean", update Visual Studio, Windows,
Cygwin, ... but once it's built if I want to update my local repo to
retrieve a new patch it will fail in 99%.
Sometimes cleaning the module is enough but most
Hi Regina,
On 28.01.2023 21:30, Regina Henschel wrote:
Hi all,
I get the following link error.
unocontrol.o : error LNK2019: unresolved external symbol "public:
virtual void __cdecl toolkit::OAccessibleControlContex
t::release(void)" (?release@OAccessibleControlContext@toolki
On 1/28/2023 10:30 AM, Regina Henschel wrote:
Hi all,
I get the following link error.
Cratch my last reply, I just realized that this had been accidentally
sorted into the wrong folder in my email client... :(
Ralf
On 1/28/2023 10:30 AM, Regina Henschel wrote:
Hi all,
I get the following link error.
unocontrol.o : error LNK2019: unresolved external symbol "public:
virtual void __cdecl toolkit::OAccessibleControlContex
t::release(void)"
(?release@OAccessibleControlContext@toolkit@@UEAAXXZ)
Hi all,
I get the following link error.
unocontrol.o : error LNK2019: unresolved external symbol "public:
virtual void __cdecl toolkit::OAccessibleControlContex
t::release(void)" (?release@OAccessibleControlContext@toolkit@@UEAAXXZ)
referenced in function "public: __cdecl
Hi Noel,
thank you for the help. It works now.
Kind regards
Regina
Noel Grandin schrieb am 16.02.2021 um 08:37:
On 2021/02/16 12:22 am, Regina Henschel wrote:
Hi Noel,
my local build on Windows 10 with VS2019 works, but gerrit_mac and
gerrit_android_x86_64 complain.
https://gerrit.libreoff
On 2021/02/16 12:22 am, Regina Henschel wrote:
Hi Noel,
my local build on Windows 10 with VS2019 works, but gerrit_mac and
gerrit_android_x86_64 complain.
https://gerrit.libreoffice.org/c/core/+/110959
Windows linking is a little more relaxed in this area, which is why problems
tend to show
Hi Noel,
my local build on Windows 10 with VS2019 works, but gerrit_mac and
gerrit_android_x86_64 complain.
https://gerrit.libreoffice.org/c/core/+/110959
I still need help.
Kind regards
Regina
Noel Grandin schrieb am 14.02.2021 um 06:52:
Hi
You will need to annotate those methods with SC
Hi Noel,
Noel Grandin schrieb am 14.02.2021 um 06:52:
Hi
You will need to annotate those methods with SC_DLLPUBLIC
to make them visible to the unit tests
OK. That solves the link problem. But I wonder, why it is needed for
FuConstUnoControl and not needed for FuConstCustomShape.
Kind rega
Hi
You will need to annotate those methods with SC_DLLPUBLIC
to make them visible to the unit tests
-- Noel Grandin
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Hi all,
I have added a unit test
ScShapeTest::testTdf134355_DragCreateCustomShape()
in /sc/qa/unit/scshapetest.cxx
https://git.libreoffice.org/core/+/02e4f6c44295004f5c7201a7aa2744fd0518ba9d
Now I want to do the same with a form control. But I get link errors
'unresolved external symbol' about F
memory usage than its x86-64 bit counterpart.
Up until these recent 2 regressions (jpeg-turbo and mulodi4) , I've been
building 32-bit builds with Clang for the past couple of years.
--
View this message in context:
http://nabble.documentfoundation.org/Link-error-undefined-referen
On 05/02/2017 06:39 PM, slacka wrote:
Whatever the trouble with your toolchain
If you have access to a Fedora x86 box with Clang, I'm sure you'd see this
too as I'm seeing this on both my 32-bit Fedora box with Clang 5.0 master
and 32-bit Ubuntu box with clang 3.9.
tweak the #elif so that yo
se the #else fallback implementation
So you don't think this sound like a compiler issue? Anything else you
suggest I try or look into before working on a patch for this?
--
View this message in context:
http://nabble.documentfoundation.org/Link-error-undefined-reference-to-mulodi4-with-Clang-32-
On 05/01/2017 05:09 PM, Luke Benes wrote:
/core/workdir/CxxObject/tools/source/generic/fract.o: In function
`Fraction::operator*=(Fraction const&)':
/core/tools/source/generic/fract.cxx:(.text+0x695): undefined reference to
`__mulodi4'
/core/tools/source/generic/fract.cxx:(.text+0x70a): undefin
Commit
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4f0b226600fdad4e5aef9313fe8754c765cfee42
Check for overflow in multiply
is causing a build error with Clang 4.0 and 5.0 x86. Reverting this commit
resolves the error.
[build DEP] LNK:Library/libtllo.so
[build LNK] Library/libtllo.
> Maybe my local installation of Python 3.4 has to do with this problem?
>
>
Could well be. Make sure it is not found in PATH when running autogen.sh.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailm
Hey all,
I try to build on OS X 10.9.5 and get this link error at libpyuno.dylib:
Library/libpyuno.dylib
ld: library not found for -lpython2.7
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make[1]: ***
[/Users/Joost/work/lo/core/instdir/LibreOfficeDev.app
sctl/source/basicide/baside2b.cxx. When I type make basic, that
works, but when I compile the basctl module, it give me link error on
CodeCompleteDataCache class's function. My working progress ca be
found
here:http://cgit.freedesktop.org/libreoffice/core/log/?h=feature/gsoc-basic-ide-comple
sic, that works,
but when I compile the basctl module, it give me link error on
CodeCompleteDataCache class's function. My working progress ca be found
here:
http://cgit.freedesktop.org/libreoffice/core/log/?h=feature/gsoc-basic-ide-completion-and-other-bits
. Can
anybody tell me a solution
On Fri, 2011-08-05 at 10:04 +0530, Marc-André Laverdière wrote:
> Hi Eike, Caolan, *
>
> I recall that some exploits in the past have been done by linking to a
> symbol that wasn't hidden but should've... in other words the attackers
> bypassed the method/function with the argument validity checks
Hi Marc-André,
On Friday, 2011-08-05 10:04:14 +0530, Marc-André Laverdière wrote:
> I recall that some exploits in the past have been done by linking to a
> symbol that wasn't hidden but should've... in other words the attackers
> bypassed the method/function with the argument validity checks.
N
On Fri, 5 Aug 2011 01:45:35 +0200
Eike Rathke wrote:
> Fortunately those split repos will be gone soon :-)
Yes, and I will be celebrating in the streets on that day. ;)
On a sidenote: Yes, _set_defs has been replaced by _add_defs by
Michael Stahl on gnumake4.
Best,
Bjoern
--
https://launchp
Hi Eike, Caolan, *
I recall that some exploits in the past have been done by linking to a
symbol that wasn't hidden but should've... in other words the attackers
bypassed the method/function with the argument validity checks.
So here's my follow-up question :)
Anything in that/those module(s) tha
Hi,
On Friday, 2011-08-05 01:12:03 +0200, Eike Rathke wrote:
> Now I wonder whether gb_Library_add_defs was introduced newly and not
> committed to solenv/gbuild/ or I should change all _add_ to _set_ and
> add $$(DEFS) at all places.
Mystery solved: working with stgit I forgot to invoke stgit r
Hi Bjoern,
On Friday, 2011-08-05 00:49:57 +0200, Eike Rathke wrote:
> note _SET_defs, so I changed that to
>
> $(eval $(call gb_Library_set_defs,ucbhelper,\
> $$(DEFS) \
> -DUCBHELPER_DLLIMPLEMENTATION \
> ))
>
> and that works. Apparently all modules newly converted to gbuild have
> th
Hi Bjoern,
On Friday, 2011-08-05 00:02:53 +0200, Bjoern Michaelsen wrote:
> UCBHELPER_DLLIMPLEMENTATION is set during the compiles.
That seems to be the underlying cause: UCBHELPER_DLLIMPLEMENTATION is
_not_ set during compilation, Library_ucbhelper.mk has
$(eval $(call gb_Library_add_defs,ucbh
Hi Bjoern,
On Friday, 2011-08-05 00:02:53 +0200, Bjoern Michaelsen wrote:
> Well, indeed gnumake should only care about the symbols marked via
> UCBHELPER_DLLPUBLIC (from ucbhelper/inc/ucbhelper/ucbhelperdllapi.h)
> which should expand to
>__attribute__((visibility("default")))
> for linux v
On Thu, 4 Aug 2011 21:22:54 +0200
Eike Rathke wrote:
> But I was lying when I said before the symbols were there, well, they
> are, but local, nm gives 't' instead of 'T'. Apparently the gnumake
> transition switched visibility to all-off. Looking at the dmake build
> there was ucbhelper.flt used
Hi Caolán,
On Thursday, 2011-08-04 21:22:54 +0200, Eike Rathke wrote:
> > I don't think moving from dmake to gnumake should affect this.
> I think it did..
>
> But I was lying when I said before the symbols were there, well, they
> are, but local, nm gives 't' instead of 'T'. Apparently the gnum
Hi Caolán,
On Thursday, 2011-08-04 09:19:37 +0100, Caolán McNamara wrote:
> I don't think moving from dmake to gnumake should affect this.
I think it did..
> I think the gnumake one gets copied out into the old solver hierarchy.
> Nevertheless that's what I'd check. See how many libucbhelper4gc
On Thu, 2011-08-04 at 01:40 +0200, Eike Rathke wrote:
> I'm currently stuck. Ideas, anyone?
I don't think moving from dmake to gnumake should affect this. I think
the gnumake one gets copied out into the old solver hierarchy.
Nevertheless that's what I'd check. See how many libucbhelper4gcc3.so
yo
Hi,
building master (as of this evening with origin
23f430a7dea74ee4eeb797ae5874384e34da362f in libs-gui) unxlngi6 gave
a linker error in comphelper complaining about undefined references that
should be provided by ucbhelper, for example
ucbhelper::Content::Content()
ucbhelper is built, libucbhel
On Mon, 23 May 2011 13:08:56 +0200
Thorsten Behrens
wrote:
> In case that's not solved yet - you want either gnumake 3.82, or a
> patched 3.81 - Björn had a helpful list of needed fixes somewhere.
Here is a package for ubuntu/debian:
https://launchpad.net/~libreoffice/+archive/ppa/+sourcepub/17
Andreas Radke wrote:
> /bin/sh: line 1: 10897 Segmentation fault make -r -j10
>
In case that's not solved yet - you want either gnumake 3.82, or a
patched 3.81 - Björn had a helpful list of needed fixes somewhere.
HTH,
-- Thorsten
pgpS8hvQmGKWZ.pgp
Description: PGP signature
__
Andreas Radke wrote:
> /bin/sh: line 1: 10897 Segmentation fault make -r -j10
>
In case that's not solved yet - you want either gnumake 3.82, or a
patched 3.81 - Björn had a helpful list of needed fixes somewhere.
HTH,
-- Thorsten
pgphz10SyfG5v.pgp
Description: PGP signature
__
Testing now with 3.4rc1 I'm running into a similar break even on x86_64:
Entering /build/src/build/helpcontent2/source/text/shared/guide
/build/src/build/swext/mediawiki/build.xml:79: warning: 'includeantruntime' was
not set, defaulting to build.sysclasspath=last; set to false for repeatable
bu
On Tue, 2011-05-17 at 19:55 +0200, Andreas Radke wrote:
> I'm always trying to build packages for ArchLinux with your upstream
> source tarballs. No git or 2nd run builds.
Ah ! how exciting :-) I imagine as we get closer to release, that has
even more of a chance of working - but clearly,
Am Tue, 17 May 2011 18:36:15 +0100
schrieb Michael Meeks :
> And - well ;-) yes, it looks like a nastily odd linking /
> compiling / assembling error.
>
> You tried re-building from 'make clean' in sc/ ? Either way
> hopefully Kohei can chase it on IRC with you.
I'm always trying to
Hi there,
On Fri, 2011-05-06 at 20:29 +0200, Andreas Radke wrote:
> non-smp fails also. I'm attaching the end of the log.
So - this was still a threaded build, and the real link error was in
sc, best to paste the commands in (that show which module to build
inside):
[ build
45 matches
Mail list logo
