Hi all.

In my program I need to use the OpenSSL unit from fpc (packages/openssl) AND
I also need to use the lNET package.

However my problem is that lNET also include a file named openssl.pas, although it
seems to be never that the one included in packages it does not have the same
methods included.

So wheneven I include OpenSSL as a unit in my program it ALWAYS refer to the one
in lNET, presumable because it is a package - how do I avoid this and instead
use/refer to the fpc one?

Regards,
-Torsten.

Simply said: You can't. The lnet one needs to be renamed. One day when namespaces will be generally used, that should solve itself. (but then that is of course the same as renaming)

Michael.

On Tue, Nov 17, 2015 at 8:15 AM, Michael Van Canneyt <

Why not make -Fu option be "package" specific instead? In this case "lnet" would search for openssl.pas in its own directory rather than packages/openssl ?

Since the compiler doesn't operate a "package"entity, make it based of the directory structure.
(Due to nature of package sources, which typically reside in their own directory).
For example:
for any source in "./lnet" use "-Fu./"
default "-Fu./package/ssl"

It's sort of namespace based on the file names.

As a result no actual namespace, code changes or file renaming are needed.

thanks,
Dmitry

Dmitry Boyarintsev wrote on Tue, 17 Nov 2015:

Why not make -Fu option be "package" specific instead? In this case "lnet" would search for openssl.pas in its own directory rather than packages/openssl ?

It would be a special case hack that would not solve the general problem. E.g., the text mode ide doesn't compile on OS X, because it uses a "dialogs" unit and there's one in both freevision and univint.

Jonas

Because the 'package' idea does not exist in the compiler. It is an informal concept. The formal concept are... namespaces.

Michael.

On Tue, Nov 17, 2015 at 8:35 AM, Michael Van Canneyt <

Yep, that's exactly why it's directory based. Due to a practice of separating packages into a stand alone directory.
It's an idea to resolve the issue by using configuration rather than by changing the (existing/old) source code.

Or is it planned to identify a namespace by it's physical location? (through another configuration setting?)

Jonas Maebe wrote

It would be a special case hack that would not solve the general problem. E.g., the text mode ide doesn't compile on OS X, because it uses a "dialogs" unit and there's one in both freevision and univint.

Make the option to be per directory, but also per file? (Something similar to delphi's "uses unit in 'filepath'? but for search directories).

off-topic: In the particular case of IDE for OSX, shouldn't macosall.pas be used? That should eliminate the need of univint/dialogs.pas

thanks,
Dmitry

I fail to see how this will solve the problem that you want to use 2 units with the same name at the same time, as for the OP.

Or is it planned to identify a namespace by it's physical location? (through another configuration setting?)

Not that I am aware of.

Michael.

On Tue, Nov 17, 2015 at 9:19 AM, Michael Van Canneyt <

I presume in this case the compiler would recognize that lnet code should use "lnet/openssl.pas" instead.
Which should end up in a separate openssl??.o file that would be passed to the linker.

While both source files are named the same, two different object files would be produced.

thanks,
Dmitry

How should the linker know which of the equally named symbols should be linked in out of those equally named object files then?

Tomas

Tomas Hajny wrote

How should the linker know which of the equally named symbols should be linked in out of those equally named object files then? Let me ask you this: why should they be equally named?

thanks,
Dmitry

Some ideas
http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path

Marcos Douglas

First, the two units serve as interfaces to the same external library, thus they provide the same functions with the same parameters. Second, they even come from the same original codebase, so even the functionality added on top of what is included in the external library probably matches at least partly. Rules defined in the compiler for naming symbols in object files are deterministic - the same function header in a unit having the same name would always get the same symbol. Thus at least some of the symbols would be equally named in those two object files.

Tomas

Tomas Hajny wrote

First, the two units serve as interfaces to the same external library, thus they provide the same functions with the same parameters.

For the external functions, it shouldn't be a it's happening today, since it's allowed to reference the same external function via different names/units in pascal. i.e. WinAPI functions are usually referenced from a custom written units. But later are added to rlt windows.pas unit. So the custom written unit compiles just fine.
So, in the end keeping the reference to an external function name the same is ok.

Second, they even come from the same original codebase, so even the functionality added on top of what is included in the external library probably matches at least partly.

Custom (pascal-level) code has to be split (unless 100% the same). Thus if both lnet/openssl.pas and fcl/openssl.pas are providing the same function (i.e. sslinit), but have different pascal code (not just an external reference), object names for these function should be unique.

I guess, the biggest issue here is that "packages" are being precompiled (using the same names), thus either sources are necessary to recompile and change the name or object files has to be modified to make names unique.

thanks,
Dmitry

As Michael wrote it is not possible without unit renaming because there is no notion of package in compiler.
The proper solution is to compile lNET package as a library (static library doesn't supported AFAIK but DLL is ok).
Then write a small wrapper to import some types, classes, and functions and use DLL with shared memory.

If you're required a really large interface of this package and then large wrapper to write, you should better decompose your application to compile some part as DLL with lNET package only.

Regards,
Serguei

Op 17-11-15 om 13:28 schreef Torsten Bonde Christiansen:

Just use the latest version of lnet, in which this problem has been solved.

If you are using 3.0.0, easiest is to do 'fppkg install lnet'

Joost.

Thank you for your suggestion - but to be honest I think the easiest way for me is going to be: Use Lazarus to rename the OpenSSL unit from lnet, which hopefully renames all reference within the package itself.

Regards,
Torsten.

Op 18-11-15 om 08:00 schreef Torsten Bonde Christiansen:

But where did you install lnet from in the first place? Just update to the latest version isn't that hard? I do not know which version you are using, but if it is a recent one, the rename of the openssl unit is the only change. ;)

Btw: the openssl unit form lnet is exactly the same as the openssl unit in fpc.

Joost.

I've been using the one from here:
http://svn.freepascal.org/svn/fpcprojects/lnet/tags/release_0_6_5

Btw: the openssl unit form lnet is exactly the same as the openssl unit in fpc.

Maybe the trunk of lnet is updated, but otherwise there is actually a large difference in the two units. A whole lot of RSA/PEM and other certificate functions are not included in the lnet one. I made a quick diff of the two files (lnet vs. fpc opensl) and it is more than 100K bytes large... :)

Regards,
Torsten.

if that is so, then why still distribute it with lnet ?

Michael.

Op 18-11-15 om 13:52 schreef Michael Van Canneyt:

It is not.

Joost.

Op 18-11-15 om 13:52 schreef Torsten Bonde Christiansen:

That version is a few years old, use trunk instead.

The problem is that the original maintainer is not active anymore, so there are no new releases.

Regards,

Joost.

There've been a few changes to e.g. admit the possibility of using IP6, and I've added a bit of stuff related to Telnet (not very good, I'd hasten to say, but enough to do a specific job).

My understanding is that lnet is not formally part of FPC, but is included as a convenience. It is outside the usual package scheme, and is part of neither the RTL nor FCL.

So irrespective of lnet's merits, if there's a conflict with any part of the RTL or FCL, it loses.