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
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
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
https://bugs.documentfoundation.org/show_bug.cgi?id=137487
--- Comment #4 from LeroyG ---
Still present in https://help.libreoffice.org/7.3/.
--
You are receiving this mail because:
You are the assignee for the bug.
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.
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
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
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
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
https://bugs.documentfoundation.org/show_bug.cgi?id=137487
pavlog changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://bugs.documentfoundation.org/show_bug.cgi?id=137487
pavlog changed:
What|Removed |Added
CC||pavlograd...@gmail.com
https://bugs.documentfoundation.org/show_bug.cgi?id=137487
--- Comment #2 from pavlog ---
Created attachment 167278
--> https://bugs.documentfoundation.org/attachment.cgi?id=167278=edit
screenshot
--
You are receiving this mail because:
You are the assignee for the
https://bugs.documentfoundation.org/show_bug.cgi?id=137487
--- Comment #1 from Leroy ---
The same in offline help of LibreOffice 6.4.7.2 (x86).
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
https://bugs.documentfoundation.org/show_bug.cgi?id=137487
QA Administrators changed:
What|Removed |Added
Whiteboard|| QA:needsComment
--
You
https://bugs.documentfoundation.org/show_bug.cgi?id=137487
Bug ID: 137487
Summary: [LOCALHELP] Link error in Convert - Table to Text;
also seen in [WIKIHELP]
Product: LibreOffice
Version: unspecified
Hardware: All
https://bugs.documentfoundation.org/show_bug.cgi?id=120181
Xisco Faulí changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bugs.documentfoundation.org/show_bug.cgi?id=120181
--- Comment #4 from BogdanB ---
I agree with Bernard on "The solution is to define a "context language" which
can be by default the "interface language" with a proposal to automatic or
manual switch."
For example in romanian language
https://bugs.documentfoundation.org/show_bug.cgi?id=120181
--- Comment #3 from Bernard TREMBLAY ---
Hi,
I have not well understood what you mean by :
<>
About the answer for "romania" and the "help" language, I think that is linked
to but opens on another problem.
There is no reason that if I
https://bugs.documentfoundation.org/show_bug.cgi?id=120181
Xisco Faulí changed:
What|Removed |Added
CC||xiscofa...@libreoffice.org
https://bugs.documentfoundation.org/show_bug.cgi?id=120181
BogdanB changed:
What|Removed |Added
CC||bogdan...@gmail.com
--- Comment #1
https://bugs.documentfoundation.org/show_bug.cgi?id=120181
Bug ID: 120181
Summary: A link error on main feedback page
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
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-reference
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
llback 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-bit-tp4213636p421368
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):
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]
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
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
/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-completion-and-other-bits . Can
,
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 to this problem?
Regards
https://bugs.freedesktop.org/show_bug.cgi?id=51936
Bug #: 51936
Summary: Run-time link error (warning?) messages at every
start-up
Classification: Unclassified
Product: LibreOffice
Version: unspecified
Platform: x86
On Fri, 5 Aug 2011 01:45:35 +0200
Eike Rathke o...@erack.de 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
--
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.
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.
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
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
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 gnumake
On Thu, 4 Aug 2011 21:22:54 +0200
Eike Rathke o...@erack.de 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
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 via
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
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
that
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
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)
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,
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
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
On Mon, 23 May 2011 13:08:56 +0200
Thorsten Behrens
t...@documentfoundation.org 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:
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 CXX ] sc
Am Tue, 17 May 2011 18:36:15 +0100
schrieb Michael Meeks michael.me...@novell.com:
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.
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,
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
55 matches
Mail list logo
