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
13 matches
Mail list logo
