World: r3wp

Do you have a problem with making an embedded delayed extension that 
loads cURL dynamically when the extension is imported? This is supposed 
to be possible, and is the main reason for delayed modules and extensions. 
Then only programs with Needs: [curl] would initialize curl.

Yes, I have a problem with that. It's way too much work for making 
a file extension dynamic, and it breaks most of my use cases

There are many platforms that use the same file extensions, so you'll 
have to find a way to put the BSD .so files in another directory 
from the Linux .so files. The .rx extension just adds Windows and 
OSX to that.

That's merely a problem of organising download directories

I'm sorry that you got used to loading extensions without needing 
to turn off the security restrictions in R3. If it helps you to know, 
you can also specify modules to import on the command line, or put 
your platform-specific delayed module loads in %rebol.r.

%rebol.r is sort of an addon to the host code.

The security setting is not the issue here

The common use case is a modular operating system. You have a standard 
R3 installed. During the life of the system, you install new extensions 
and programs. R3 makes the extensions be operating system dynamic 
libraries and lets the OS look for them, so they must be installed 
in the OS. You don't want to also have to embed each new extension 
in a new R3 binary. You want to install and write separate REBOL 
scripts that load these extensions, and you want those scripts to 
be cross-platform, because they easily can be

So, you want to make a modular OS that has all dynamic libraries 
be R3 extensions natively - LOAD-EXTENSION won't load arbitrary libraries, 
just extensions - and you want the library filename suffix to be 
something other than .rx. OK.

LOAD-EXTENSION doesn't do lookup beyond the current directory, so 
if you want to have it use some library path you have to add that 
in the host code, or %rebol.r. Either way you can add extensions 
and modules programmatically to the R3 runtime before the script 
you're running starts. If you want your scripts to be cross-platform 
then you probably shouldn't use a platform-specific file extension 
for the files, but if they are loaded or delayed in the host code 
or %rebol.r then it wouldn't matter.

What's the problem? Even in R2 I was using code like:
	lib_ImageMagickWand: load/library either system/version/4 = 3 [
		%/c/utils/ImageMagick/CORE_RL_wand_.dll
	][	%/usr/lib/libMagickWand.so ]

I prefere to have this under control. The location may differ on 
different platforms.

For that matter, code like that can go in %rebol.r and then scripts 
won't have to even know that an extension isn't a regular module, 
as long as the API matches what they expect.

Oldes, R3 has decided to let the OS find an extension as a native 
library. I really don't want to override that and write my own loader 
in every script

Are you saying that on Linux and/or Syllable LOAD-EXTENSION looks 
up the extensions in the system library path? Weird.

Not weird, nice :-)

You may want to review my documentation for the cURL binding

Too late at night for me to read documentation :(

It's the logical effect of using the system's loader

https://github.com/Oldes/R3A110/blob/master/extensions/zlib/zlib.r3

I'm going to sleep, too

That sounds really dangerous with security turned off. Be careful.

Don't worry, I am the master of my systems

I don't get it Oldes. Why is it called %zlib-rxt.dll, when it could 
just as easily be called %zlib.rx and not have the platform-specific 
code?

Yes

But either way, that works.

I'm a newbie.. I expect that when I build DLL against windows version 
of the lib, it will not work on Linux.. or maybe I'm wrong.

That's true, but it's not tied to the name, Brian tells us

True. You would use a different file for Linux, though it could also 
be called %zlib.rx :)

I admit I confuse people by violating this truth and running the 
Linux binary on Syllable :-)

But than I need zlib.dll and zlib.so in the folder.. and what if 
I don't have zlib.so yet?

Since they don't work on both OSes, you wouldn't install them both. 
You install the matching one under the same name

Then don't have zlib.rx in that directory either :)

What is content of zlib.rx?

The R3 extension wrapper for ZLib.

that's the zlib.r3 for me.

Or the R3 extension that statically links ZLib if you like.

I don't get it.. I will wait for real life example..I'm fine how 
I have it now.

In your case you could just rename zlib-rxt.dll to zlib.rx and it 
would work.

And it will work on Linux?

You would then import %zlib.rx instead of %zlib.r3. It would work 
on Linux if you made a Linux build of zlib as a R3 extension and 
also called it zlib.rx.

But I want to make clear that the file is DLL, not SO.

maybe I will need my extension on linux later so I will make the 
SO, and I want both in the same directory, not just one, which I 
use at this moment. I want to have my files structure platform independent.

Why? Don't you put other platforms' extensions in different directories? 
There are multiple platforms that use .dll and .so, remember.

no... I use same structure.

And when you install it you don't need to install other platforms, 
just the platform you're on. So you only install the zlib.rx for 
your platform.

I do not install... I just copy folders. the true is, that now it 
can be more complicated as I have also the C sources in the same 
dir.

never mind... this is just a minor detail. Form me is important I 
can decompress zlib data as I could with R2. That's all.

If I had more time, it would be good to try some zlib/gz scheme.. 
but that's not important for me at this moment.

What is more important - can we UNLOAD the extension?

I thought that was included in R3 now?