Dear Eul-Shik:
Thank you for your reply.
Eul-Shik Hong wrote:
>
> This is in response to Case ID: 252132
>
> Dear Dr. Reimer:
>
> I am writing in response to your e-mail of 6/24/99 regarding the problem
> that you were seeing using FCLOSE with the MATLAB ENGINE.
>
> You wrote:
> *****
> 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)?
> *****
>
> I have tried to reproduce the problem in the following manner:
>
> - Run the makefile to compile the code. However, I had to make some
> modifications to have the makefile work:
The makefile I supplied was tested before submitting and found to run
fine under RedHat Linux 5.0, 5.1, 5.2, and 6.0 in conjunction with
MATLAB 5.1, 5.2, and 5.3. I just have tested it under RH 4.1 (which
comes with GNU make 3.74) and it runs fine even there, too!
That is why I guess that you did not correctly save my attached
makefile. Using the mouse to copy it will most likely loose tabs and/or
add additional carriage returns which will make it unusable. In order to
correctly save the attached make file as well as the c++ file do the
following (works for Netscape 4.5 and 4.6):
For messages with attachments there will be a little gadget in the lower
right corner of the message frame. Drag it up to open a new frame which
will show icons for the attached files. Over the icons push the right
mouse button and choose "Save..." to save.
Additionally, let me explain the lines you have changed in my makefile
because it seems to me that you did not understand them:
ifndef MATLAB # If MATLAB was not already defined
# as environment variable
MATLAB = /usr/local/matlab # then set it to the default
# system location
endif # end the ifndef construction
>
> # 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 = /$MATLAB
> #endif
> LDFLAGS =
> -Wl,-R$(MATLAB)/extern/lib/lnx86:$(MATLAB)/sys/os/lnx86:$(MATLAB)/sys
> /lnx86 -ldl
>
> all: $(TARGET)
>
> clean:
> rm -f $(TARGET) core
>
> - Once the executable was generated the LD_LIBRARY_PATH was set to:
>
> setenv LD_LIBRARY_PATH $MATLAB/extern/lib/lnx86
Setting LD_LIBRARY_PATH is not necessary if the binary was compiled with
option
"-Wl,-R$(MATLAB)/extern/lib/lnx86:$(MATLAB)/sys/os/lnx86:$(MATLAB)/sys/lnx".
This Linker option will compile the specified paths into the binary so
that DLLs will be searched in the specified paths before searching in
the standard search paths (the directories specified in the file
/etc/ld.so.conf, and the trusted directories /usr/lib and /lib).
>
> - Then the executable was run, without any problems.
If it ran fine with you then I guess that you did not run it under
RedHat 6.0. The bug will not show up under RedHat versions before 6.0!
If you did not run it under RedHat 6.0 then you did not look at the
subject of this mail (it says: RedHat 6.0 with glibc2.1.1) and you did
not look at the bug description in matlabifc_test.cc (it also says:
glibc2.1.1 based ix86 Linux (e.g. RedHat Linux 6.0))
>
> If you are still having problems you may wish to make sure that your paths
> are set correctly and that you are linking to the correct libraries:
>
> http://www.mathworks.com/support/solutions/v5/23237.shtml
I always double-check whether all related paths are set correctly and I
already searched the news groups and read the stuff on that page before
(!) submitting the bug message. Unfortunately, this is not applicable to
our problem. In order to make it more clear let me explain the problem
in the context:
We are working on a huge c++ project. The classes of this project are
strongly based on the recent Standard Template Library (libstdc++ 2.9.x)
and make use of many of it's advanced features (such as exception
handling). Libstdc++ 2.9 requires glibc 2.x and there there is no way
to link our program against old libc5 based libstdc++ (which does not
support e.g. exception handling). The reported bug showed up in our
project. So we traced it down (it was a hard piece of work after all)
and
created the tiny c++ testfile to demonstrate the isolated bug.
>
> You may also wish to make sure that you have the following files in your
> $MATLAB/extern/lib/lnx86 directory:
>
> libmat.so* libmcc.so* libmmfile.so* version4.o
> libmatlb.so* libmccmx.so* libmx.so*
> libeng.so* libmatpp.so* libmi.so* libut.so*
>
> I hope this helps!
>
> Sincerely,
>
> Eul-Shik Hong
> Technical Support Engineer
> [EMAIL PROTECTED]
>
Unfortunately, it did not help. But I have a suggestions for a clean(!)
solution, which could also help all of your customers having a similar
problem:
It is not(!) necessary to recompile the whole matlab project (It just
runs fine so far with the compatibility libs in $MATLAB/sys/os/lnx86
under RH6.0). In order to solve the interface problem it is sufficient
to only recompile the interface libraries for the external side (i.e.
only the stuff under $MATLAB/extern/lib/lnx86).
Because it is urgent here is MY OFFER: I would volunteer to recompile
the interface libraries under RedHat Linux 6.0 (x86) for you so that you
can make them available to others. It is only necessary to give me the
sources of the interface stuff and additionally I would even sign a NDA
to avoid any legal problems for you. This way we could
1) solve our problem in a short term,
2) have a clean solution (not just a work around), and
3) help all of your customers having a similar problem.
I you have any doubts on my seriousness and/or programming skills: You
can trace e.g. my voluntary work
(http://www.deja.com/%5BST_rn=ps%5D/qs.xp?ST=PS&DBS=1&OP=dnquery.xp&groups=comp.soft-sys.ptolemy&authors=reimer&showsort=date&maxhits=100)
doing the Linux port of the Ptolemy project
(http://ptolemy.berkeley.edu/) in Berkeley.
Best regards,
Wolfgang.
PS: I again attached the testfile and the makefile. Additionally, I
attached the log of the output created when compiling and debugging the
binary under RedHat Linux 6.0 (x86).
--
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
// 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;
}
# 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
[reimer@kapella test_c]$ rpm -q redhat-release
redhat-release-6.0-1
[reimer@kapella test_c]$ export MATLAB=/usr/local/matlab5.3
[reimer@kapella test_c]$ make clean
rm -f matlabifc_test core
[reimer@kapella test_c]$ make
g++ -ggdb3
-Wl,-R/usr/local/matlab5.3/extern/lib/lnx86:/usr/local/matlab5.3/sys/os/lnx86:/usr/local/matlab5.3/sys/lnx86
-ldl matlabifc_test.cc -o matlabifc_test
[reimer@kapella test_c]$ gdb matlabifc_test
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r
Starting program: /home/reimer/test_c/matlabifc_test
Program received signal SIGSEGV, Segmentation fault.
0x400cba70 in _IO_new_fclose (fp=0x804b4a8) at iofclose.c:45
iofclose.c:45: No such file or directory.
Current language: auto; currently c
(gdb) bt
#0 0x400cba70 in _IO_new_fclose (fp=0x804b4a8) at iofclose.c:45
#1 0x400159d6 in engClose ()
#2 0x8048ba9 in main () at matlabifc_test.cc:52
#3 0x40092cb3 in __libc_start_main (main=0x8048a40 <main>, argc=1, argv=0xbffff7d4,
init=0x8048880 <_init>, fini=0x8048c0c <_fini>, rtld_fini=0x4000a350 <_dl_fini>,
stack_end=0xbffff7cc) at ../sysdeps/generic/libc-start.c:78
(gdb) quit
The program is running. Exit anyway? (y or n) y
[reimer@kapella test_c]$
