Compiling dynamic libraries with 6.2

[urudaro]

We have been using Eiffel in our system since ten years. Our system
relies largely on modules implemented in Eiffel targeted as shared
libraries. Mostly have our system been delivered for Windows using DLLs.
We have ported the system to Linux and Eiffel 5.6. Everything had
worked fine there.
But.., when we tried to port to Eiffel 6.x on Linux (Ubuntu 8.04), we
met problems.

The system compiles fine but we get segmentation faults each time call
exported functions in the libraries.

We first suspected something wrong in our system. So I set up a
minimalistic system exporting a function:

class
        APPLICATION

create
        make

feature -- Initialization

        make is
                do
                end

        export_test is
                        --
                do
                        print ("Executing %"export_test%"%N")
                end
end -- class APPLICATION

With the following exportation specification:

"APPLICATION make export_test"

Even this system build as a shared library brings a segmentation fault
when it is called.

I traced the problem to the allocation of the object of APPLICATION
type in the stub of the function export_test in "edynlib.c":

extern void F2_6116 (EIF_REFERENCE);
extern void F2_6117 (EIF_REFERENCE);
void export_test_1 (void)
{ GTCX
        /* Creation : F2_6116; */
        /* Feature  : F2_6117 ;*/
        EIF_REFERENCE main_obj = (EIF_REFERENCE) 0;
        DYNAMIC_LIB_RT_INITIALIZE(1);

RTLR(0,main_obj);
        main_obj = RTLN(1);
        /* Call the creation routine */
        F2_6116(main_obj);

        /* Call the routine */
        F2_6117(main_obj);
        DYNAMIC_LIB_RT_END;
}

The segmentation fault occurs in the line:
        main_obj = RTLN(1);


This seems to me that this is a general problem in compiling shared
libraries in Eiffel 6.x.

Has anyone had problems with this?

... or are we missing something?

Can anyone assist?

Regards

/Daniel Rodriguez


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf]

I found that the reason of the failure is unlike a Windows DLL that has some
initialization code, a Unix shared library does not. So you need to initialize the
runtime the same way you would initialize a CECIL library.

Hope this helps,
Manu

> -----Original Message-----
> From: eiffel_software@...
> [mailto:eiffel_software@...] On Behalf Of urudaro
> Sent: Wednesday, July 09, 2008 12:38 PM
> To: eiffel_software@...
> Subject: [eiffel_software] Compiling dynamic libraries with 6.2
>
> We have been using Eiffel in our system since ten years. Our system
> relies largely on modules implemented in Eiffel targeted as shared
> libraries. Mostly have our system been delivered for Windows using DLLs.
> We have ported the system to Linux and Eiffel 5.6. Everything had
> worked fine there.
> But.., when we tried to port to Eiffel 6.x on Linux (Ubuntu 8.04), we
> met problems.
>
> The system compiles fine but we get segmentation faults each time call
> exported functions in the libraries.
>
> We first suspected something wrong in our system. So I set up a
> minimalistic system exporting a function:
>
> class
> APPLICATION
>
> create
> make
>
> feature -- Initialization
>
> make is
> do
> end
>
> export_test is
> --
> do
> print ("Executing %"export_test%"%N")
> end
> end -- class APPLICATION
>
> With the following exportation specification:
>
> "APPLICATION make export_test"
>
> Even this system build as a shared library brings a segmentation fault
> when it is called.
>
> I traced the problem to the allocation of the object of APPLICATION
> type in the stub of the function export_test in "edynlib.c":
>
> extern void F2_6116 (EIF_REFERENCE);
> extern void F2_6117 (EIF_REFERENCE);
> void export_test_1 (void)
> { GTCX
> /* Creation : F2_6116; */
> /* Feature  : F2_6117 ;*/
> EIF_REFERENCE main_obj = (EIF_REFERENCE) 0;
> DYNAMIC_LIB_RT_INITIALIZE(1);
>
> RTLR(0,main_obj);
> main_obj = RTLN(1);
> /* Call the creation routine */
> F2_6116(main_obj);
>
> /* Call the routine */
> F2_6117(main_obj);
> DYNAMIC_LIB_RT_END;
> }
>
> The segmentation fault occurs in the line:
> main_obj = RTLN(1);
>
>
> This seems to me that this is a general problem in compiling shared
> libraries in Eiffel 6.x.
>
> Has anyone had problems with this?
>
> ... or are we missing something?
>
> Can anyone assist?
>
> Regards
>
> /Daniel Rodriguez
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Paul Cohen]

Hi,

On Tue, Jul 15, 2008 at 6:16 AM, Emmanuel Stapf [ES] <manus@...> wrote:
> I found that the reason of the failure is unlike a Windows DLL that has some
> initialization code, a Unix shared library does not. So you need to
> initialize the
> runtime the same way you would initialize a CECIL library.

Are you saying that this is not a bug, but intended behaviour? I think
it is a *very* serious drawback that one can't build .so libraries on
Linux/Unix as easily as one can build .dll:s on Windows with
EiffelStudio, especially as this worked fine in 5.6.

Do you have a pointer to the relevant and updated documentation for
CECIL? There is no documentation included in the installation on
Linux.

Another problem is that that the dynamic libraries on Linux export all
the generated (mangled) C symbols in the system which leads to symbol
clashes when building systems with more that one Eiffel-based .so
file.

I think it is very important for Eiffel to show a strong prescence on
Linux. Remember that the Unix/Linux design philosophy emphasizes
modularization and decomposition which on that platform very often is
realized by creating .so/.a binary modules and accompanying C API:s so
support for building .so/.a files on Linux is important.

/Paul

--
Paul Cohen
mobile: [phone]
e-mail: paul.cohen@...

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf]

> Are you saying that this is not a bug, but intended behaviour? I think
> it is a *very* serious drawback that one can't build .so libraries on
> Linux/Unix as easily as one can build .dll:s on Windows with
> EiffelStudio, especially as this worked fine in 5.6.

It is certainly not the intended behavior but it looks like unlike Windows, Unix
shared libraries do not have a standardized way to have some initialization code
being called before any access to the shared library.

> Do you have a pointer to the relevant and updated documentation for
> CECIL? There is no documentation included in the installation on
> Linux.

It is in your documentation in $ISE_EIFFEL/docs or at http://docs.eiffel.com. The
CECIL pages are at:
http://docs.eiffel.com/eiffelstudio/technologies/cecil

> Another problem is that that the dynamic libraries on Linux export all
> the generated (mangled) C symbols in the system which leads to symbol
> clashes when building systems with more that one Eiffel-based .so
> file.

That's correct, but I'm not sure if there is a way to prevent this on all
platforms. Looks like there are some GCC specific extensions that could allow that
but I'm not sure if they work on all versions of GCC.

Regards,
Manu



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Paul Cohen]

On Tue, Jul 15, 2008 at 9:41 PM, Emmanuel Stapf [ES] <manus@...> wrote:

>> Are you saying that this is not a bug, but intended behaviour? I think
>> it is a *very* serious drawback that one can't build .so libraries on
>> Linux/Unix as easily as one can build .dll:s on Windows with
>> EiffelStudio, especially as this worked fine in 5.6.
>
> It is certainly not the intended behavior but it looks like unlike Windows,
> Unix
> shared libraries do not have a standardized way to have some initialization
> code
> being called before any access to the shared library.

Ok. That sounds a bit strange. Are you talking about different *nix
object file formats here, ie. ELF, COFF etc? Can't that be solved by
having #ifdef:s for different os:s and architectures?

>> Do you have a pointer to the relevant and updated documentation for
>> CECIL? There is no documentation included in the installation on
>> Linux.
>
> It is in your documentation in $ISE_EIFFEL/docs or at
> http://docs.eiffel.com. The
> CECIL pages are at:
> http://docs.eiffel.com/eiffelstudio/technologies/cecil

Ok. Thanks. I was slightly put of by the copyright 2006 and no
indication to whether that information was updated.

>> Another problem is that that the dynamic libraries on Linux export all
>> the generated (mangled) C symbols in the system which leads to symbol
>> clashes when building systems with more that one Eiffel-based .so
>> file.
>
> That's correct, but I'm not sure if there is a way to prevent this on all
> platforms. Looks like there are some GCC specific extensions that could
> allow that
> but I'm not sure if they work on all versions of GCC.

Ok. We have a working solution to that for gcc/linux, but it is an annoyance.

Also, in the EiffelStudio implementation of shared libraries a root
object is created for each call to the library. Is there any
particular reason for that? I assume it has to do with how the GC
works. However any effective features declared as once in the root
class remain alive over multiple calls, That's how state can be
handled in shared libraries.

It would be more efficient from a performance perspective if the root
object could remain alive until the library is unloaded from memory.

Any comments?

/Paul

--
Paul Cohen
mobile: [phone]
e-mail: paul.cohen@...

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf]

> Ok. That sounds a bit strange. Are you talking about different *nix
> object file formats here, ie. ELF, COFF etc? Can't that be solved by
> having #ifdef:s for different os:s and architectures?

Possibly. I just don't know enough of each platform specifics to provide a more
complete answer.
 
> Ok. Thanks. I was slightly put of by the copyright 2006 and no
> indication to whether that information was updated.

CECIL is much older and the documentation is always valid.
 
> Also, in the EiffelStudio implementation of shared libraries a root
> object is created for each call to the library. Is there any
> particular reason for that? I assume it has to do with how the GC
> works. However any effective features declared as once in the root
> class remain alive over multiple calls, That's how state can be
> handled in shared libraries.

It has nothing to do with the GC, but to Eiffel which always need an object to
perform a call. So for each exported routine we create an instance of the proper
type. Of course using once is the secret to maintain state, but it does not change
the fact that you need an object.
 
> It would be more efficient from a performance perspective if the root
> object could remain alive until the library is unloaded from memory.

This is something we have thought of but the cost of allocating a tiny object is
really close to nothing in practice so we did not bother trying to do this which
would require yet another option that would need explanation.

Hope this helps,
Manu


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Paul Cohen]

Hi,

On Wed, Jul 16, 2008 at 6:17 AM, Emmanuel Stapf [ES] <manus@...> wrote:
>> Ok. That sounds a bit strange. Are you talking about different *nix
>> object file formats here, ie. ELF, COFF etc? Can't that be solved by
>> having #ifdef:s for different os:s and architectures?
>
> Possibly. I just don't know enough of each platform specifics to provide a
> more
> complete answer.

Ok. We need to solve it for Linux ELF & gcc anyway. We would be glad
to contribute a solution for inclusion in the next release.

>> It would be more efficient from a performance perspective if the root
>> object could remain alive until the library is unloaded from memory.
>
> This is something we have thought of but the cost of allocating a tiny
> object is
> really close to nothing in practice so we did not bother trying to do this
> which
> would require yet another option that would need explanation.

Ok. I still think one should always look at performance improvements
but I agree there are cases when the
gained-performance-to-invested-effort ratio is too low.

Thanks for the help, Manu.

/Paul

--
Paul Cohen
mobile: [phone]
e-mail: paul.cohen@...

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Emmanuel Stapf]

> Ok. We need to solve it for Linux ELF & gcc anyway. We would be glad
> to contribute a solution for inclusion in the next release.

Great. Can you submit a problem report at http://support.eiffel.com and from there
we will see how best fix this for 6.3.

Thanks,
Manu


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/