octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with glob <=> rpl_glob


From: John W. Eaton
Subject: Re: Problem with glob <=> rpl_glob
Date: Wed, 20 Jan 2010 02:00:32 -0500

On 20-Jan-2010, John W. Eaton wrote:

| On 18-Jan-2010, Michael Goffioul wrote:
| 
| | On Sun, Jan 17, 2010 at 3:57 PM, John W. Eaton <address@hidden> wrote:
| | > On 17-Jan-2010, Michael Goffioul wrote:
| | >
| | > | I'm having a problem with an undefined to glob_match::glob
| | > | at link time, similar to what used to happen with MinGW (iirc).
| | > |
| | > | Looking at the fix implemented in
| | > | http://hg.savannah.gnu.org/hgweb/octave/rev/fdc3a43c0be8
| | > | it seems to rely on the assumption that the compiler *will*
| | > | inline the code of glob_match::glob. Of course MSVC does not
| | > | seem to do it (sigh). I'm not sure this is a C++ requirement,
| | > | but if it's not, maybe a more reliable work around could be found?
| | >
| | > OK, I think I understand the problem here and I'll try to fix it.
| | 
| | A simple workaround that works for me is to move the inclusion
| | of glob.h and fnmatch.h (though the latter is not really required)
| | *after*¨the inclusion of glob-match.h in glob-match.cc.
| | So the symbol generated in liboctave is glob and not rpl_glob.
| | 
| | This should be harmless.
| 
| I thought about doing that, but decided to use the following change
| instead.
| 
|   http://hg.savannah.gnu.org/hgweb/octave

Sorry, I hit send too quickly.  I meant this change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/805a83ecd3da

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]