Re: Stricter dlopen?

[Beuc]

Hi,

I won't have time to follow-up on this bug (I already have quite a few
and I need to make progress on my actual port, plus I'm not directly
impacted anymore).
If anybody wants to step in, please do :)

- Sylvain

On 29/01/2019 01:19, 'Sam Clegg' via emscripten-discuss wrote:
> I agree that this seems to be a regression we should fix.  Would you
> mind opening a bug?
>
> On Thu, Jan 24, 2019 at 10:51 AM Beuc  wrote:
>> I'm not sure how this should work; AFAICS dlopen works even with static 
>> binaries under GNU/Linux.
>> To the least, printing out the name of the failed symbol would help 
>> understand the context.
>>
>> - Beuc
>>
>> On 24/01/2019 18:54, Alon Zakai wrote:
>>
>> I see, thanks. So should we make dlopen/dlsym just return "library/symbol 
>> not found" if dynamic linking is not present? Would that have avoided the 
>> confusing error for you?
>>
>>
>> On Thu, Jan 24, 2019 at 8:48 AM Beuc  wrote:
>>> The issue turns out a bit more twisted, I used to query "glReadBuffer", 
>>> which doesn't exist in GLES2, and wasn't used it my code anyway.
>>>
>>> The SDL2 port actually already calls SDL_GL_GetProcAddress => 
>>> device->GL_GetProcAddress => Emscripten_GLES_GetProcAddress => 
>>> SDL_EGL_GetProcAddress => _this->egl_data->eglGetProcAddress => 
>>> _emscripten_GetProcAddress (no less ;)).
>>>
>>> When this fails, however, SDL then tries SDL_LoadFunction => dlopen.
>>> Which I assume used to return NULL, and now raises an exception.
>>>
>>> Dropping the non-existing function call while still using 
>>> SDL_GL_GetProcAddress for the rest also solves the issue in my case.
>>>
>>> This makes SDL_GL_GetProcAddress still work but less forgiving (with a 
>>> confusing error message).
>>>
>>> - Beuc
>>>
>>> On 24/01/2019 16:20, Alon Zakai wrote:
>>>
>>> Oh, thanks, I missed that this was for SDL_GL_GetProcAddress getting GL 
>>> functions specifically. That should definitely still work. Maybe what's 
>>> going on is that the SDL code calls dlopen? Instead, it should call 
>>> emscripten_GetProcAddress (impl is in system/lib/gl/gl.c). Looks like we 
>>> need to add it to emscripten.h too. Beuc, is that change to SDL practical?
>>>
>>> On Thu, Jan 24, 2019 at 3:09 AM キャロウ　マーク  wrote:


> On Jan 23, 2019, at 8:35, Alon Zakai  wrote:
>
> Well, what I think happened is we used to have a very simple dlopen, and 
> when we rewrote it to be more powerful, we simplified it to only work on 
> linkable code. So the case of a module loading symbols from itself is a 
> case that is not well handled, you're right, it adds overhead there. 
> However, perhaps you can work around it in the code, avoid using dlopen 
> and get the function pointers directly?
>
 This change apparently broke SDL_GL_GetProcAddress, the complaint at the 
 start of this thread. Suggesting workarounds is not acceptable, except as 
 a strictly temporary measure. The SDL port needs to be fixed. Given that 
 most Open GL {,ES} applications dynamically obtain their function 
 pointers, you need to consider other fixes too. Such as EGLGetProcAddress 
 in the EGL emulation.

 Regards
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

['Sam Clegg' via emscripten-discuss]

I agree that this seems to be a regression we should fix.  Would you
mind opening a bug?

On Thu, Jan 24, 2019 at 10:51 AM Beuc  wrote:
>
> I'm not sure how this should work; AFAICS dlopen works even with static 
> binaries under GNU/Linux.
> To the least, printing out the name of the failed symbol would help 
> understand the context.
>
> - Beuc
>
> On 24/01/2019 18:54, Alon Zakai wrote:
>
> I see, thanks. So should we make dlopen/dlsym just return "library/symbol not 
> found" if dynamic linking is not present? Would that have avoided the 
> confusing error for you?
>
>
> On Thu, Jan 24, 2019 at 8:48 AM Beuc  wrote:
>>
>> The issue turns out a bit more twisted, I used to query "glReadBuffer", 
>> which doesn't exist in GLES2, and wasn't used it my code anyway.
>>
>> The SDL2 port actually already calls SDL_GL_GetProcAddress => 
>> device->GL_GetProcAddress => Emscripten_GLES_GetProcAddress => 
>> SDL_EGL_GetProcAddress => _this->egl_data->eglGetProcAddress => 
>> _emscripten_GetProcAddress (no less ;)).
>>
>> When this fails, however, SDL then tries SDL_LoadFunction => dlopen.
>> Which I assume used to return NULL, and now raises an exception.
>>
>> Dropping the non-existing function call while still using 
>> SDL_GL_GetProcAddress for the rest also solves the issue in my case.
>>
>> This makes SDL_GL_GetProcAddress still work but less forgiving (with a 
>> confusing error message).
>>
>> - Beuc
>>
>> On 24/01/2019 16:20, Alon Zakai wrote:
>>
>> Oh, thanks, I missed that this was for SDL_GL_GetProcAddress getting GL 
>> functions specifically. That should definitely still work. Maybe what's 
>> going on is that the SDL code calls dlopen? Instead, it should call 
>> emscripten_GetProcAddress (impl is in system/lib/gl/gl.c). Looks like we 
>> need to add it to emscripten.h too. Beuc, is that change to SDL practical?
>>
>> On Thu, Jan 24, 2019 at 3:09 AM キャロウ　マーク  wrote:
>>>
>>>
>>>
>>> > On Jan 23, 2019, at 8:35, Alon Zakai  wrote:
>>> >
>>> > Well, what I think happened is we used to have a very simple dlopen, and 
>>> > when we rewrote it to be more powerful, we simplified it to only work on 
>>> > linkable code. So the case of a module loading symbols from itself is a 
>>> > case that is not well handled, you're right, it adds overhead there. 
>>> > However, perhaps you can work around it in the code, avoid using dlopen 
>>> > and get the function pointers directly?
>>> >
>>>
>>> This change apparently broke SDL_GL_GetProcAddress, the complaint at the 
>>> start of this thread. Suggesting workarounds is not acceptable, except as a 
>>> strictly temporary measure. The SDL port needs to be fixed. Given that most 
>>> Open GL {,ES} applications dynamically obtain their function pointers, you 
>>> need to consider other fixes too. Such as EGLGetProcAddress in the EGL 
>>> emulation.
>>>
>>> Regards
>
> --
> You received this message because you are subscribed to the Google Groups 
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[Beuc]

I'm not sure how this should work; AFAICS dlopen works even with static
binaries under GNU/Linux.
To the least, printing out the name of the failed symbol would help
understand the context.

- Beuc

On 24/01/2019 18:54, Alon Zakai wrote:
> I see, thanks. So should we make dlopen/dlsym just return
> "library/symbol not found" if dynamic linking is not present? Would
> that have avoided the confusing error for you?
>
>
> On Thu, Jan 24, 2019 at 8:48 AM Beuc  > wrote:
>
> The issue turns out a bit more twisted, I used to query
> "glReadBuffer", which doesn't exist in GLES2, and wasn't used it
> my code anyway.
>
> The SDL2 port actually already calls SDL_GL_GetProcAddress =>
> device->GL_GetProcAddress => Emscripten_GLES_GetProcAddress =>
> SDL_EGL_GetProcAddress => _this->egl_data->eglGetProcAddress =>
> _emscripten_GetProcAddress (no less ;)).
>
> When this fails, however, SDL then tries SDL_LoadFunction => dlopen.
> Which I assume used to return NULL, and now raises an exception.
>
> Dropping the non-existing function call while still using
> SDL_GL_GetProcAddress for the rest also solves the issue in my case.
>
> This makes SDL_GL_GetProcAddress still work but less forgiving
> (with a confusing error message).
>
> - Beuc
>
> On 24/01/2019 16:20, Alon Zakai wrote:
>> Oh, thanks, I missed that this was for SDL_GL_GetProcAddress
>> getting GL functions specifically. That should definitely still
>> work. Maybe what's going on is that the SDL code calls dlopen?
>> Instead, it should call emscripten_GetProcAddress (impl is in
>> system/lib/gl/gl.c). Looks like we need to add it to emscripten.h
>> too. Beuc, is that change to SDL practical?
>>
>> On Thu, Jan 24, 2019 at 3:09 AM キャロウ　マーク > > wrote:
>>
>>
>>
>> > On Jan 23, 2019, at 8:35, Alon Zakai > > wrote:
>> >
>> > Well, what I think happened is we used to have a very
>> simple dlopen, and when we rewrote it to be more powerful, we
>> simplified it to only work on linkable code. So the case of a
>> module loading symbols from itself is a case that is not well
>> handled, you're right, it adds overhead there. However,
>> perhaps you can work around it in the code, avoid using
>> dlopen and get the function pointers directly?
>> >
>>
>> This change apparently broke SDL_GL_GetProcAddress, the
>> complaint at the start of this thread. Suggesting workarounds
>> is not acceptable, except as a strictly temporary measure.
>> The SDL port needs to be fixed. Given that most Open GL {,ES}
>> applications dynamically obtain their function pointers, you
>> need to consider other fixes too. Such as EGLGetProcAddress
>> in the EGL emulation.
>>
>> Regards
>>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[Alon Zakai]

I see, thanks. So should we make dlopen/dlsym just return "library/symbol
not found" if dynamic linking is not present? Would that have avoided the
confusing error for you?


On Thu, Jan 24, 2019 at 8:48 AM Beuc  wrote:

> The issue turns out a bit more twisted, I used to query "glReadBuffer",
> which doesn't exist in GLES2, and wasn't used it my code anyway.
>
> The SDL2 port actually already calls SDL_GL_GetProcAddress =>
> device->GL_GetProcAddress => Emscripten_GLES_GetProcAddress =>
> SDL_EGL_GetProcAddress => _this->egl_data->eglGetProcAddress =>
> _emscripten_GetProcAddress (no less ;)).
>
> When this fails, however, SDL then tries SDL_LoadFunction => dlopen.
> Which I assume used to return NULL, and now raises an exception.
>
> Dropping the non-existing function call while still using
> SDL_GL_GetProcAddress for the rest also solves the issue in my case.
>
> This makes SDL_GL_GetProcAddress still work but less forgiving (with a
> confusing error message).
>
> - Beuc
> On 24/01/2019 16:20, Alon Zakai wrote:
>
> Oh, thanks, I missed that this was for SDL_GL_GetProcAddress getting GL
> functions specifically. That should definitely still work. Maybe what's
> going on is that the SDL code calls dlopen? Instead, it should call
> emscripten_GetProcAddress (impl is in system/lib/gl/gl.c). Looks like we
> need to add it to emscripten.h too. Beuc, is that change to SDL practical?
>
> On Thu, Jan 24, 2019 at 3:09 AM キャロウ マーク  wrote:
>
>>
>>
>> > On Jan 23, 2019, at 8:35, Alon Zakai  wrote:
>> >
>> > Well, what I think happened is we used to have a very simple dlopen,
>> and when we rewrote it to be more powerful, we simplified it to only work
>> on linkable code. So the case of a module loading symbols from itself is a
>> case that is not well handled, you're right, it adds overhead there.
>> However, perhaps you can work around it in the code, avoid using dlopen and
>> get the function pointers directly?
>> >
>>
>> This change apparently broke SDL_GL_GetProcAddress, the complaint at the
>> start of this thread. Suggesting workarounds is not acceptable, except as a
>> strictly temporary measure. The SDL port needs to be fixed. Given that most
>> Open GL {,ES} applications dynamically obtain their function pointers, you
>> need to consider other fixes too. Such as EGLGetProcAddress in the EGL
>> emulation.
>>
>> Regards
>>
>> -Mark
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[Beuc]

The issue turns out a bit more twisted, I used to query "glReadBuffer",
which doesn't exist in GLES2, and wasn't used it my code anyway.

The SDL2 port actually already calls SDL_GL_GetProcAddress =>
device->GL_GetProcAddress => Emscripten_GLES_GetProcAddress =>
SDL_EGL_GetProcAddress => _this->egl_data->eglGetProcAddress =>
_emscripten_GetProcAddress (no less ;)).

When this fails, however, SDL then tries SDL_LoadFunction => dlopen.
Which I assume used to return NULL, and now raises an exception.

Dropping the non-existing function call while still using
SDL_GL_GetProcAddress for the rest also solves the issue in my case.

This makes SDL_GL_GetProcAddress still work but less forgiving (with a
confusing error message).

- Beuc

On 24/01/2019 16:20, Alon Zakai wrote:
> Oh, thanks, I missed that this was for SDL_GL_GetProcAddress getting
> GL functions specifically. That should definitely still work. Maybe
> what's going on is that the SDL code calls dlopen? Instead, it should
> call emscripten_GetProcAddress (impl is in system/lib/gl/gl.c). Looks
> like we need to add it to emscripten.h too. Beuc, is that change to
> SDL practical?
>
> On Thu, Jan 24, 2019 at 3:09 AM キャロウ　マーク  > wrote:
>
>
>
> > On Jan 23, 2019, at 8:35, Alon Zakai  > wrote:
> >
> > Well, what I think happened is we used to have a very simple
> dlopen, and when we rewrote it to be more powerful, we simplified
> it to only work on linkable code. So the case of a module loading
> symbols from itself is a case that is not well handled, you're
> right, it adds overhead there. However, perhaps you can work
> around it in the code, avoid using dlopen and get the function
> pointers directly?
> >
>
> This change apparently broke SDL_GL_GetProcAddress, the complaint
> at the start of this thread. Suggesting workarounds is not
> acceptable, except as a strictly temporary measure. The SDL port
> needs to be fixed. Given that most Open GL {,ES} applications
> dynamically obtain their function pointers, you need to consider
> other fixes too. Such as EGLGetProcAddress in the EGL emulation.
>
> Regards
>
>     -Mark
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to emscripten-discuss+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to emscripten-discuss+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[Alon Zakai]

Oh, thanks, I missed that this was for SDL_GL_GetProcAddress getting GL
functions specifically. That should definitely still work. Maybe what's
going on is that the SDL code calls dlopen? Instead, it should call
emscripten_GetProcAddress (impl is in system/lib/gl/gl.c). Looks like we
need to add it to emscripten.h too. Beuc, is that change to SDL practical?

On Thu, Jan 24, 2019 at 3:09 AM キャロウ マーク  wrote:

>
>
> > On Jan 23, 2019, at 8:35, Alon Zakai  wrote:
> >
> > Well, what I think happened is we used to have a very simple dlopen, and
> when we rewrote it to be more powerful, we simplified it to only work on
> linkable code. So the case of a module loading symbols from itself is a
> case that is not well handled, you're right, it adds overhead there.
> However, perhaps you can work around it in the code, avoid using dlopen and
> get the function pointers directly?
> >
>
> This change apparently broke SDL_GL_GetProcAddress, the complaint at the
> start of this thread. Suggesting workarounds is not acceptable, except as a
> strictly temporary measure. The SDL port needs to be fixed. Given that most
> Open GL {,ES} applications dynamically obtain their function pointers, you
> need to consider other fixes too. Such as EGLGetProcAddress in the EGL
> emulation.
>
> Regards
>
> -Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[キャロウ マーク]

> On Jan 23, 2019, at 8:35, Alon Zakai  wrote:
> 
> Well, what I think happened is we used to have a very simple dlopen, and when 
> we rewrote it to be more powerful, we simplified it to only work on linkable 
> code. So the case of a module loading symbols from itself is a case that is 
> not well handled, you're right, it adds overhead there. However, perhaps you 
> can work around it in the code, avoid using dlopen and get the function 
> pointers directly?
> 

This change apparently broke SDL_GL_GetProcAddress, the complaint at the start 
of this thread. Suggesting workarounds is not acceptable, except as a strictly 
temporary measure. The SDL port needs to be fixed. Given that most Open GL 
{,ES} applications dynamically obtain their function pointers, you need to 
consider other fixes too. Such as EGLGetProcAddress in the EGL emulation.

Regards

-Mark

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Stricter dlopen?

[Beuc]

Yeah that's how I had fixed it:
https://git.savannah.gnu.org/cgit/freedink.git/commit/?id=b879f418619a8e87e0bb614e4b84ca054cb8cfe9
Glad to see we came to the same conclusion :)

- Beuc

On 23/01/2019 00:35, Alon Zakai wrote:
> Well, what I think happened is we used to have a very simple dlopen,
> and when we rewrote it to be more powerful, we simplified it to only
> work on linkable code. So the case of a module loading symbols from
> itself is a case that is not well handled, you're right, it adds
> overhead there. However, perhaps you can work around it in the code,
> avoid using dlopen and get the function pointers directly?
>
> On Tue, Jan 22, 2019 at 2:53 PM Beuc  > wrote:
>
> Hi,
>
> To be honest I didn't try MAIN_MODULE=1, because this is
> documented as being slower, and incompatible with
> Emterpreter/pthreads/etc.
> I'm somewhat puzzled it worked before really, I'm asking to make
> sure I didn't miss something obvious.
>
> - Beuc
>
> On 22/01/2019 23:27, Alon Zakai wrote:
>> Maybe the error is not clear enough - I think all you need to do
>> is build with -s MAIN_MODULE=1. Does that fix things for you?
>>
>> On Tue, Jan 22, 2019 at 6:29 AM Beuc > > wrote:
>>
>> Hi,
>>
>> For the GNU FreeDink project, which has a custom OpenGL
>> loader, I use
>> code like:
>>
>>     BlendFunc = (void (APIENTRY*)(GLenum sfactor, GLenum
>> dfactor))SDL_GL_GetProcAddress("glBlendFunc");
>>
>> This stopped working recently, I believe this still worked in
>> 1.38.21
>> which I used for my last build, though the error message I
>> now get was
>> introduced in 538f958a900 (right before that version):
>>
>>     +    abort("To use dlopen, you need to use Emscripten's
>> linking
>> support, see
>> https://github.com/kripken/emscripten/wiki/Linking;);
>>
>>
>> I guess Emscripten previously supported loading symbols from
>> the current
>> binary, and now rejects it?
>>
>> While it makes sense to modify FreeDink to locate GL functions
>> statically under Emscripten, I don't see anything related in
>> ChangeLog.md, so I'd like to make sure.
>>
>> -- 
>> Beuc
>>
>> -- 
>> You received this message because you are subscribed to the
>> Google Groups "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to
>> emscripten-discuss+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> You received this message because you are subscribed to the
>> Google Groups "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to emscripten-discuss+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
> -- 
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to emscripten-discuss+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to emscripten-discuss+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[Alon Zakai]

Well, what I think happened is we used to have a very simple dlopen, and
when we rewrote it to be more powerful, we simplified it to only work on
linkable code. So the case of a module loading symbols from itself is a
case that is not well handled, you're right, it adds overhead there.
However, perhaps you can work around it in the code, avoid using dlopen and
get the function pointers directly?

On Tue, Jan 22, 2019 at 2:53 PM Beuc  wrote:

> Hi,
>
> To be honest I didn't try MAIN_MODULE=1, because this is documented as
> being slower, and incompatible with Emterpreter/pthreads/etc.
> I'm somewhat puzzled it worked before really, I'm asking to make sure I
> didn't miss something obvious.
>
> - Beuc
> On 22/01/2019 23:27, Alon Zakai wrote:
>
> Maybe the error is not clear enough - I think all you need to do is build
> with -s MAIN_MODULE=1. Does that fix things for you?
>
> On Tue, Jan 22, 2019 at 6:29 AM Beuc  wrote:
>
>> Hi,
>>
>> For the GNU FreeDink project, which has a custom OpenGL loader, I use
>> code like:
>>
>> BlendFunc = (void (APIENTRY*)(GLenum sfactor, GLenum
>> dfactor))SDL_GL_GetProcAddress("glBlendFunc");
>>
>> This stopped working recently, I believe this still worked in 1.38.21
>> which I used for my last build, though the error message I now get was
>> introduced in 538f958a900 (right before that version):
>>
>> +abort("To use dlopen, you need to use Emscripten's linking
>> support, see https://github.com/kripken/emscripten/wiki/Linking;);
>>
>>
>> I guess Emscripten previously supported loading symbols from the current
>> binary, and now rejects it?
>>
>> While it makes sense to modify FreeDink to locate GL functions
>> statically under Emscripten, I don't see anything related in
>> ChangeLog.md, so I'd like to make sure.
>>
>> --
>> Beuc
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[Beuc]

Hi,

To be honest I didn't try MAIN_MODULE=1, because this is documented as
being slower, and incompatible with Emterpreter/pthreads/etc.
I'm somewhat puzzled it worked before really, I'm asking to make sure I
didn't miss something obvious.

- Beuc

On 22/01/2019 23:27, Alon Zakai wrote:
> Maybe the error is not clear enough - I think all you need to do is
> build with -s MAIN_MODULE=1. Does that fix things for you?
>
> On Tue, Jan 22, 2019 at 6:29 AM Beuc  > wrote:
>
> Hi,
>
> For the GNU FreeDink project, which has a custom OpenGL loader, I use
> code like:
>
>     BlendFunc = (void (APIENTRY*)(GLenum sfactor, GLenum
> dfactor))SDL_GL_GetProcAddress("glBlendFunc");
>
> This stopped working recently, I believe this still worked in 1.38.21
> which I used for my last build, though the error message I now get was
> introduced in 538f958a900 (right before that version):
>
>     +    abort("To use dlopen, you need to use Emscripten's linking
> support, see https://github.com/kripken/emscripten/wiki/Linking;);
>
>
> I guess Emscripten previously supported loading symbols from the
> current
> binary, and now rejects it?
>
> While it makes sense to modify FreeDink to locate GL functions
> statically under Emscripten, I don't see anything related in
> ChangeLog.md, so I'd like to make sure.
>
> -- 
> Beuc
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to emscripten-discuss+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to emscripten-discuss+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stricter dlopen?

[Alon Zakai]

Maybe the error is not clear enough - I think all you need to do is build
with -s MAIN_MODULE=1. Does that fix things for you?

On Tue, Jan 22, 2019 at 6:29 AM Beuc  wrote:

> Hi,
>
> For the GNU FreeDink project, which has a custom OpenGL loader, I use
> code like:
>
> BlendFunc = (void (APIENTRY*)(GLenum sfactor, GLenum
> dfactor))SDL_GL_GetProcAddress("glBlendFunc");
>
> This stopped working recently, I believe this still worked in 1.38.21
> which I used for my last build, though the error message I now get was
> introduced in 538f958a900 (right before that version):
>
> +abort("To use dlopen, you need to use Emscripten's linking
> support, see https://github.com/kripken/emscripten/wiki/Linking;);
>
>
> I guess Emscripten previously supported loading symbols from the current
> binary, and now rejects it?
>
> While it makes sense to modify FreeDink to locate GL functions
> statically under Emscripten, I don't see anything related in
> ChangeLog.md, so I'd like to make sure.
>
> --
> Beuc
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.