Wolfgang's original message was over 40k, so it got bounced
by Majordomo, so it did not go out to ptolemy-hackers subscribers

I've hacked off the bottom part of the message and I'm resending it.

-Christopher



Date: Thu, 06 Apr 2000 19:52:00 +0200
From: Wolfgang Reimer <[EMAIL PROTECTED]>
Organization: Ilmenau Univ. of Technology, Germany
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-10smp i686)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.soft-sys.matlab
To: Craig Hughes <[EMAIL PROTECTED]>
CC: VP Developers <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
        Ptolemy Hackers <[EMAIL PROTECTED]>
Subject: Re: MATLAB 5 under redhat 6.x (glibc2.1/libc5 problems)
References: <[EMAIL PROTECTED]>
Content-Type: multipart/digest;
 boundary="------------CC0949232932875D64EE8DE8"

This is a multi-part message in MIME format.
--------------CC0949232932875D64EE8DE8
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

> Craig Hughes wrote:
> 
> Wolfgang,
> 
>     I saw your posting to the redhat-devel-list (archived on redhat's
> site) about trying to get the matlab-linked-against-libc5 binaries to
> work happily in a glibc2.1 world.  The posting is dated June of last
> year, and I was wondering if you'd had any success in getting this
> working?  I'm having similar difficulties in trying to use the MATLAB
> compiler and MEX files under redhat 6.1 -- no matter what I do I can't
> get mex to link things against libc.so.5 instead of libc.so.6 nor can
> I figure out any way of fixing the problem.  Your having tracked this
> down to fclose() is somewhat useful to me, but unfortunately in using
> MEX files, the shared lib gets loaded to core, then the file is closed
> before it's executed, so I get a SIGSEV instantly if I try to run
> compiled code.  I don't know what if any progress you've made with
> either MathWorks or Redhat in solving this, but I thought I'd try and
> contact you before calling these guys.
> 
> Thanks for any help
> 
> C

Hi Craig:

I am sorry to let you know that I did not get any positive response from
MathWorks since then. This could mean that either they did not fix the
problem during the last ten month or they fixed it and they did not let
me know about a fix. As you possibly know, I even offered them to sign a
NDA and to port their external interface library (only the part which
must be linked against the non-MATLAB application needs to be ported)
but they would not let me (for details see the mail thread in the
attachment).

Finally, I gave up on this and the glibc based Linux port of our
respective software does not have an interface to MATLAB. We had to tell
our Linux customers about this fact and of course they weren't very
happy about it. Some of them which really needed the interface to MATLAB
had to move either to an older Linux version or even to an other OS.

I guess in your case the problem is simpler. You have a pure MATLAB
application which (with some fiddling) should also build and link using
libc5 libraries whereas our software (we have a non-MATLAB application
which requires the features of the new glibc/libstdc++) cannot be built
and linked against old libc5.

In order to build and link against old libc5 you will need the
appropriate libc5 header files (they must be in include path before any
libc6 related stuff) and all the libc5 related DLLs (libc, libm ...). If
I remember correctly, you also need to use some special compiler
switches.

In any case if you find out any news please let me know about it.

Best regards,

Wolfgang.
-- 
Wolfgang Reimer (Dr.-Ing.)
 
Technische Universität Ilmenau - Ilmenau University of Technology
Address:   TU Ilmenau, FEI/IKM, PF 100565, 98684 Ilmenau, GERMANY
http://ikmcip1.e-technik.tu-ilmenau.de    Phone: +49-3677-69-2619
mailto:[EMAIL PROTECTED]     Fax  : +49-3677-69-1195

V I R T U A L      P H O T O N I C S      I N C O R P O R A T E D
mailto:[EMAIL PROTECTED]         http://www.virtualphotonics.com
--------------CC0949232932875D64EE8DE8

X-Mozilla-Status2: 00000000
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 24 Jun 1999 00:18:35 +0200
From: Wolfgang Reimer <[EMAIL PROTECTED]>
Organization: Technical Univ. of Ilmenau
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.1.125 i686)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.soft-sys.matlab
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: VP Developers <[EMAIL PROTECTED]>,
        [EMAIL PROTECTED],
        Ptolemy Hackers <[EMAIL PROTECTED]>
Subject: MATLAB5.x + glibc2.1.1 (RH Linux 6.0 x86): Interface bug due to libc 
 incompatibility
X-Priority: 1 (Highest)
Content-Type: multipart/mixed;
 boundary="------------687D20A36B1E54767971AACC"

This is a multi-part message in MIME format.
--------------687D20A36B1E54767971AACC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi folks:

The bug described in the attached C++ file (matlabifc_test.cc) makes the
MATLAB 5.x interface unusable if fclose() will be used in the same
program. Actually, nearly every program uses fclose(). Thus, the MATLAB
interface becomes unusable for nearly every program.

Is there any known work around for that problem (I urgently need a
short-term solution)?

Will Mathworks release new MATLAB interface libraries built and linked
against glibc2.1 (which would be a clean long-term solution to the
problem)?

Any hints will be greatly appreciated. Please send replies to my e-mail
address because I did not subscribe to the mailing lists.

Best regards,

Wolfgang.
PS: A binary of matlabifc_test.cc can be easily built using the attached
makefile.
-- 
Wolfgang Reimer (Dr.-Ing.)
 
T U I  --  Technical University of Ilmenau,  GERMANY, Thuringia
Address: TU Ilmenau, FEI/IKM, PF 100565, 98684 Ilmenau, GERMANY
http://ikmcip1.e-technik.tu-ilmenau.de  Phone: +49-3677-69-2619
mailto:[EMAIL PROTECTED]   Fax  : +49-3677-69-1195

V I R T U A L     P H O T O N I C S     I N C O R P O R A T E D
mailto:[EMAIL PROTECTED]                http://www.vp-bned.com
--------------687D20A36B1E54767971AACC
Content-Type: text/plain; charset=us-ascii;
 name="matlabifc_test.cc"
Content-Disposition: inline;
 filename="matlabifc_test.cc"
Content-Transfer-Encoding: 7bit

// Program name: matlabifc_test.cc
// Written by  : Olaf Lenzmann (with minor changes by Wolfgang Reimer)
//
// This program demonstrates a bug which shows up under glibc2.1.1 based
// ix86 Linux (e.g. RedHat Linux 6.0) in conjunction with the MATLAB 5.1,
// 5.2 and 5.3 interface libraries which were built and linked against
// obsolete Linux libc5, unfortunately.
//
// If fclose() is used somewhere in the program then inside engClose()
// the function _IO_new_fclose() will be called which will cause a SIGSEGV.
// If fclose() is not used in the program then inside engClose() the function
// _IO_old_fclose() will be called and the program runs fine.
//
// IMHO, this problem is an compatibility problem which could be solved
// cleanly if Mathworks would release also interface libaries built and
// linked against glibc2.1.
// 
// Wolfgang Reimer mailto:[EMAIL PROTECTED]

#include <dlfcn.h>
#include <stdio.h>
#include <iostream.h>

int main (void) {
    char buf[1024];

    fclose(fopen("/etc/passwd", "r")); // fclose() is only used to show the bug

    void * hnd = dlopen( "libeng.so", RTLD_LAZY );

    if( !hnd ) {
        cerr << "Could not load library" << endl;
        exit(-1);
    }

    void *(*engOpen) (const char *) = (typeof(engOpen))dlsym( hnd, "engOpen" );
    int (*engClose) (void *) = (typeof(engClose))dlsym( hnd, "engClose" );
    int (*engEvalString) (void *, const char *) = 
        (typeof(engEvalString))dlsym( hnd, "engEvalString" );
    int (*engOutputBuffer) (void *, char *, int) =
        (typeof(engOutputBuffer))dlsym( hnd, "engOutputBuffer" );

    void * eng = engOpen(NULL);

    if( !eng ) {
        cerr << "Could not open engine" << endl;
        exit(-1);
    }

    engOutputBuffer( eng, buf, 1024 );
    engEvalString( eng, "plot(1:10); pause(3);" );
    engClose(eng);
    cerr << "Done" << endl;
}

--------------687D20A36B1E54767971AACC
Content-Type: text/plain; charset=us-ascii;
 name="makefile"
Content-Disposition: inline;
 filename="makefile"
Content-Transfer-Encoding: 7bit

# Minimum makefile for matlabifc_test
# written by Wolfgang Reimer mailto:[EMAIL PROTECTED]

TARGET   = matlabifc_test

CXXFLAGS = -ggdb3
ifndef MATLAB
  # adjust MATLAB to point to your Matlab home directory
  MATLAB = /usr/local/matlab
endif
LDFLAGS  = -Wl,-R$(MATLAB)/extern/lib/lnx86:$(MATLAB)/sys/os/lnx86:$(MATLAB)/sys/lnx86 
-ldl

all: $(TARGET)

clean:
        rm -f $(TARGET) core

--------------687D20A36B1E54767971AACC--

----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Reply via email to