Uploading mingw32 octave binaries - where and how?

[Benjamin Lindner]

Hello list,

I hope this is the correct place to ask, I loked around the project and
it seemed the most appropriate list.

I'd like to (finally) contribute binary packages of octave built with
and bundled with the mingw32 gcc.

I had a look at the download section and found that there are are
already some package sections.
Now the questions is how to add the mingw32 binaries into the download
structure of the project.

What I'd like to provide is:
1) Octave mingw32 binaries
2) the corresponding Sources & Patches (Octave and all dependencies
included) - compliance to GPL etc.
3) ATLAS v3.8.1 binaries for some architectures

1) and 2) should be fairly obvious, I guess.

Item 3) should be a seperate item IMO, since these binaries do not
follow the release cycle of octave, and therefore are kind of a general
add-on to many octave binaries. I therefore would distribute them
seperately from the octave binaries.

I would suggest therefore 3 new sections, like
"octave forge windows mingw32 binaries"
"octave forge windows mingw32 sources"
"octave forge windows mingw32 atlas"

Or one could combine the atlas binaries into the binaries section be
relinking them to every new release (supposing this is possible)?
Like having the sections
"octave forge windows mingw32 binaries"
"octave forge windows mingw32 sources"
and the binaries containing, e.g.
<Octave n.n.n for Windows/mingw32>
<Octave n.n.n for Windows/mingw32 - ATLAS>
i.e. two new entries for every new version/release of octave.

Or adding the ATLAS binaries to every released binary directly. Like
"OCTAVE FORGE WINDOWS MINGW32"
<Octave n.n.n for WIndows/mingw32> - 2008-mm-dd
   - a-binary-file-of-octave
   - a-different-file-maybe-installer-or-other-zip-format-binary
   - ATLAS-binary-ARCH_1
   - ATLAS-binary-ARCH_2
   - ATLAS-binary-ARCH_3
   ...

Comments?

Aside from the structure definitions:
who can add/modify the download page structure?
who can then actually add files to the download section?
me? an admin only?


benjamin

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[dbateman]

Benjamin Lindner wrote:

I hope this is the correct place to ask, I loked around the project and
it seemed the most appropriate list.

I'd like to (finally) contribute binary packages of octave built with
and bundled with the mingw32 gcc.

Great, I added the release technician flag to your account so you can upload the binaries, the only question is where and what. I'd also suggest you look at the "releaseforge" project that is a much better means to upload than what sourceforge provides.

I had a look at the download section and found that there are are
already some package sections.
Now the questions is how to add the mingw32 binaries into the download
structure of the project.

The structure will have to be revised. At the moment there is a "Octave Forge WIndows" section and a section for additional packages. Michael has started including all packages in the NSI installer and so the additional packages subsection should go away. I'd therefore suggest having and "Octave Forge Windows - MSVC" and "Octave Forge Windows - MinGW" section on the download page.

What I'd like to provide is:
1) Octave mingw32 binaries
2) the corresponding Sources & Patches (Octave and all dependencies
included) - compliance to GPL etc.
3) ATLAS v3.8.1 binaries for some architectures

1) and 2) should be fairly obvious, I guess.

Supply the source tarball is easy enough, though huge. As for the binaries and atlas libraries, frankly I'd prefer that the whole lot was wrapped up in an NSI installer like Michael's package and the appropriate library installed as needed.

Item 3) should be a seperate item IMO, since these binaries do not
follow the release cycle of octave, and therefore are kind of a general
add-on to many octave binaries. I therefore would distribute them
seperately from the octave binaries.

I would suggest therefore 3 new sections, like
"octave forge windows mingw32 binaries"
"octave forge windows mingw32 sources"
"octave forge windows mingw32 atlas"

If the atlas is in the installer then it makes sense to keep the binary and source packages together in the same  sub-sub section of the download page.


Or one could combine the atlas binaries into the binaries section be
relinking them to every new release (supposing this is possible)?
Like having the sections
"octave forge windows mingw32 binaries"
"octave forge windows mingw32 sources"
and the binaries containing, e.g.
<Octave n.n.n for Windows/mingw32>
<Octave n.n.n for Windows/mingw32 - ATLAS>
i.e. two new entries for every new version/release of octave.

Or adding the ATLAS binaries to every released binary directly. Like
"OCTAVE FORGE WINDOWS MINGW32"
<Octave n.n.n for WIndows/mingw32> - 2008-mm-dd
   - a-binary-file-of-octave
   - a-different-file-maybe-installer-or-other-zip-format-binary
   - ATLAS-binary-ARCH_1
   - ATLAS-binary-ARCH_2
   - ATLAS-binary-ARCH_3
   ...

Comments?


NSI and a bit of help from Michael :-)  In any case I'm not sure you need all of those ATLAS libraries. I'd probably only keep SSE2 and perhaps SSE3 libraries as most machines support that and use generic blas for the rest.



Aside from the structure definitions:
who can add/modify the download page structure?
who can then actually add files to the download section?
me? an admin only?


You can now that i've added the flag :-)

D.

[Tatsuro MATSUOKA-2]

Hello

Congraturations!
I'm very glad to hear that you are in now last stage of octave for windows on mingw.
Perhaps as you know, my mental condition has been not good.
It is too hard for me both cygwin/mingw port.

Recently Macro released octave on cygwin in the official style.
However, for cygwin, the famous sjlj problem is remained so that I will continue to release
octave on cygwin by gcc-dw2.

It is hard to me to maintain my testing mingw port.
If your binary will come up, I will take a rest for the my mingw port for a while.


Regards

Tatsuro


--- Benjamin Lindner <lindnerben@...> wrote:

> Hello list,
>
> I hope this is the correct place to ask, I loked around the project and
> it seemed the most appropriate list.
>
> I'd like to (finally) contribute binary packages of octave built with
> and bundled with the mingw32 gcc.
>
> I had a look at the download section and found that there are are
> already some package sections.
> Now the questions is how to add the mingw32 binaries into the download
> structure of the project.
>
> What I'd like to provide is:
> 1) Octave mingw32 binaries
> 2) the corresponding Sources & Patches (Octave and all dependencies
> included) - compliance to GPL etc.
> 3) ATLAS v3.8.1 binaries for some architectures
>
> 1) and 2) should be fairly obvious, I guess.
>
> Item 3) should be a seperate item IMO, since these binaries do not
> follow the release cycle of octave, and therefore are kind of a general
> add-on to many octave binaries. I therefore would distribute them
> seperately from the octave binaries.
>
> I would suggest therefore 3 new sections, like
> "octave forge windows mingw32 binaries"
> "octave forge windows mingw32 sources"
> "octave forge windows mingw32 atlas"
>
> Or one could combine the atlas binaries into the binaries section be
> relinking them to every new release (supposing this is possible)?
> Like having the sections
> "octave forge windows mingw32 binaries"
> "octave forge windows mingw32 sources"
> and the binaries containing, e.g.
> <Octave n.n.n for Windows/mingw32>
> <Octave n.n.n for Windows/mingw32 - ATLAS>
> i.e. two new entries for every new version/release of octave.
>
> Or adding the ATLAS binaries to every released binary directly. Like
> "OCTAVE FORGE WINDOWS MINGW32"
> <Octave n.n.n for WIndows/mingw32> - 2008-mm-dd
>    - a-binary-file-of-octave
>    - a-different-file-maybe-installer-or-other-zip-format-binary
>    - ATLAS-binary-ARCH_1
>    - ATLAS-binary-ARCH_2
>    - ATLAS-binary-ARCH_3
>    ...
>
> Comments?
>
> Aside from the structure definitions:
> who can add/modify the download page structure?
> who can then actually add files to the download section?
> me? an admin only?
>
>
> benjamin
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Michael Goffioul-2]

On Thu, Jun 26, 2008 at 9:49 PM, dbateman <dbateman@...> wrote:

> Or adding the ATLAS binaries to every released binary directly. Like
> "OCTAVE FORGE WINDOWS MINGW32"
> <Octave n.n.n for WIndows/mingw32> - 2008-mm-dd
>   - a-binary-file-of-octave
>   - a-different-file-maybe-installer-or-other-zip-format-binary
>   - ATLAS-binary-ARCH_1
>   - ATLAS-binary-ARCH_2
>   - ATLAS-binary-ARCH_3
>   ...
>
> Comments?
>
>
> NSI and a bit of help from Michael :-)  In any case I'm not sure you need
> all of those ATLAS libraries. I'd probably only keep SSE2 and perhaps SSE3
> libraries as most machines support that and use generic blas for the rest.

My opinion is that you should put yourself in the place of a Joe user
that wants to install your package. It's not user-friendly at all to tell
him "you need to download package A; if you want feature B, you'll
also need to download package C and D; depending on your CPU
(see page E to find out your CPU architecture), you can also
download packages F1, F2 or F3, but package F1 is also compatible
with architecture F3; Oh, and by the way, you can also use the
package G, which is the same as package A, but includes F1".

OK, I'm exaggerating a little bit, but you get the point. A normal
user doesn't want to deal with that. That's why I'm playing with
installers, even with simple add-ons.

Michael.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[David Bateman]

Michael Goffioul wrote:

> My opinion is that you should put yourself in the place of a Joe user
> that wants to install your package. It's not user-friendly at all to tell
> him "you need to download package A; if you want feature B, you'll
> also need to download package C and D; depending on your CPU
> (see page E to find out your CPU architecture), you can also
> download packages F1, F2 or F3, but package F1 is also compatible
> with architecture F3; Oh, and by the way, you can also use the
> package G, which is the same as package A, but includes F1".
>
> OK, I'm exaggerating a little bit, but you get the point. A normal
> user doesn't want to deal with that. That's why I'm playing with
> installers, even with simple add-ons.
>
>  

How easy would it be to adapt you NSI script to the MinGW package? I
also think it would be a good idea to wrap the compilers and the option
to install them in the installer as this is where the MinGW installer
will excel relative to the MSVC installer.

Basically I know nothing above the NSI scripting language and avoided
learning it, but it seems that the MSVC and MinGW packages will be so
similar that the modifications in NSI for one or the other will be minimal.

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Michael Goffioul-2]

On Fri, Jun 27, 2008 at 12:24 PM, David Bateman
<David.Bateman@...> wrote:
> How easy would it be to adapt you NSI script to the MinGW package? I
> also think it would be a good idea to wrap the compilers and the option
> to install them in the installer as this is where the MinGW installer
> will excel relative to the MSVC installer.
>
> Basically I know nothing above the NSI scripting language and avoided
> learning it, but it seems that the MSVC and MinGW packages will be so
> similar that the modifications in NSI for one or the other will be minimal.

Although the file structure would probably be very similar, you might
be annoyed by tiny details, like for instance file naming convention:
- MSVC uses cruft.dll, MinGW uses libcruft.dll
- MSVC uses <name>.lib import files, MinGW uses lib<name>.a import files
- ...

All these differences have to be identified and put into some macro
to be able to use the same .nsi file from MSVC and MinGW. For instance
to address the import lib filename, you can use something like
(@...@ symbols are replaced at run-time, through sed)

!define IMPLIB_PRE @IMPLIB_PRE@
!define IMPLIB_EXT @IMPLIB_EXT@
...
File "${ROOT}/lib/${IMPLIB_PRE}zlib.${IMPLIB_EXT}"
...

Michael.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[David Bateman]

Michael Goffioul wrote:

> Although the file structure would probably be very similar, you might
> be annoyed by tiny details, like for instance file naming convention:
> - MSVC uses cruft.dll, MinGW uses libcruft.dll
> - MSVC uses <name>.lib import files, MinGW uses lib<name>.a import files
> - ...
>
> All these differences have to be identified and put into some macro
> to be able to use the same .nsi file from MSVC and MinGW. For instance
> to address the import lib filename, you can use something like
> (@...@ symbols are replaced at run-time, through sed)
>
> !define IMPLIB_PRE @IMPLIB_PRE@
> !define IMPLIB_EXT @IMPLIB_EXT@
> ...
> File "${ROOT}/lib/${IMPLIB_PRE}zlib.${IMPLIB_EXT}"
> ...
>
>  

I think you're probably the only Octave developer who understands the
mechanics of this. Maybe you could help out Benjamin?

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Michael Goffioul-2]

On Fri, Jun 27, 2008 at 12:41 PM, David Bateman
<David.Bateman@...> wrote:
> I think you're probably the only Octave developer who understands the
> mechanics of this. Maybe you could help out Benjamin?

Of course, I'll help as much as I can.

Michael.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Marco atzeri-3]

--- David Bateman  ha scritto:

> Michael Goffioul wrote:
> > Although the file structure would probably be very
> similar, you might
> > be annoyed by tiny details, like for instance file
> naming convention:
> > - MSVC uses cruft.dll, MinGW uses libcruft.dll

while for cygwin is cygcruft.dll

that caused me some headache on the
octave-3.0.x porting.

> > - MSVC uses <name>.lib import files, MinGW uses
> lib<name>.a import files

for cygwin   lib<name>.a

> > - ...
> >
> > All these differences have to be identified and
> put into some macro
> > to be able to use the same .nsi file from MSVC and
> MinGW. For instance
> > to address the import lib filename, you can use
> something like
> > (@...@ symbols are replaced at run-time, through
> sed)
> >
> > !define IMPLIB_PRE @IMPLIB_PRE@
> > !define IMPLIB_EXT @IMPLIB_EXT@
> > ...
> > File "${ROOT}/lib/${IMPLIB_PRE}zlib.${IMPLIB_EXT}"
> > ...
> >
> >  
>
> I think you're probably the only Octave developer
> who understands the
> mechanics of this. Maybe you could help out
> Benjamin?
>
> D.
>

I suspect it is time to separate Mingw and cygwin
configuration, and I am afraid I should work on it.


Marco Atzeri

cygwin-octave maintainer
 


      Hai un indirizzo email difficile da ricordare?
Scegli quello che hai sempre desiderato su Yahoo! Mail
http://it.docs.yahoo.com/nuovo_indirizzo.html

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Tatsuro MATSUOKA-2]

Hello

--- Marco Atzeri <marco_atzeri@...> wrote:

> > > - MSVC uses cruft.dll, MinGW uses libcruft.dll
>
> while for cygwin is cygcruft.dll
>
Really ? Simply building of octave on cygwin, it will be produced libcruft.dll, liboctave.dll and
liboctinterp.dll.

Did you change the name of the above dll files by yourself?
For octave 2.1.xx on cygwin, libcruft.dll, liboctave.dll and liboctinterp.dll were used.

Why  do you use the name like cygcruft.dll ?
It will grateful for me you to explain the reason of file name changes.

Regards

Tatsuro


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Michael Goffioul-2]

On Sat, Jun 28, 2008 at 5:05 AM, Tatsuro MATSUOKA <tmacchant@...> wrote:

> Hello
>
> --- Marco Atzeri <marco_atzeri@...> wrote:
>
>> > > - MSVC uses cruft.dll, MinGW uses libcruft.dll
>>
>> while for cygwin is cygcruft.dll
>>
> Really ? Simply building of octave on cygwin, it will be produced libcruft.dll, liboctave.dll and
> liboctinterp.dll.
>
> Did you change the name of the above dll files by yourself?
> For octave 2.1.xx on cygwin, libcruft.dll, liboctave.dll and liboctinterp.dll were used.
>
> Why  do you use the name like cygcruft.dll ?
> It will grateful for me you to explain the reason of file name changes.

Maybe I'm wrong, but I think this is the naming convention of
libtool under cygwin. As octave does not use libtool, this does
not apply.

Michael.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Benjamin Lindner]

Michael Goffioul wrote:

> On Thu, Jun 26, 2008 at 9:49 PM, dbateman <dbateman@...> wrote:
>> Or adding the ATLAS binaries to every released binary directly. Like
>> "OCTAVE FORGE WINDOWS MINGW32"
>> <Octave n.n.n for WIndows/mingw32> - 2008-mm-dd
>>   - a-binary-file-of-octave
>>   - a-different-file-maybe-installer-or-other-zip-format-binary
>>   - ATLAS-binary-ARCH_1
>>   - ATLAS-binary-ARCH_2
>>   - ATLAS-binary-ARCH_3
>>   ...
>>
>> Comments?
>>
>>
>> NSI and a bit of help from Michael :-)  In any case I'm not sure you need
>> all of those ATLAS libraries. I'd probably only keep SSE2 and perhaps SSE3
>> libraries as most machines support that and use generic blas for the rest.
>
> My opinion is that you should put yourself in the place of a Joe user
> that wants to install your package. It's not user-friendly at all to tell
> him "you need to download package A; if you want feature B, you'll
> also need to download package C and D; depending on your CPU
> (see page E to find out your CPU architecture), you can also
> download packages F1, F2 or F3, but package F1 is also compatible
> with architecture F3; Oh, and by the way, you can also use the
> package G, which is the same as package A, but includes F1".
>
> OK, I'm exaggerating a little bit, but you get the point. A normal
> user doesn't want to deal with that. That's why I'm playing with
> installers, even with simple add-ons.
>

I get your point, but I am personally not one of those users, and
something which annoys me every time is when I have to install a program
which simply does not need to be installed (in the windows-meaning of
installation), since it's "installation process" mereley requires
unpacking something into a directory.
Since Octave does not require anything else than unpacking it (no shell
extensions, no registry access, no driver installations, ...), well an
installer is nice (I agree) but not essential for usage of the program.

So I'd like to provide also simply a zipped archive of the binary along
with an installer version.

The binary structure IS simple - one octave binary and one (optional)
atlas binary. I agree that choosing the correct architecture requires
some thinking, but then if you don't want to think, you can use the
installer version, anyway.

benjamin

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Benjamin Lindner]

Michael Goffioul wrote:
> On Fri, Jun 27, 2008 at 12:41 PM, David Bateman
> <David.Bateman@...> wrote:
>> I think you're probably the only Octave developer who understands the
>> mechanics of this. Maybe you could help out Benjamin?
>
> Of course, I'll help as much as I can.
>
> Michael.
>

Thanks for the offer, I will come forward when questions arise.

benjamin

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Benjamin Lindner-2]

David Bateman wrote:

> Michael Goffioul wrote:
>
> How easy would it be to adapt you NSI script to the MinGW package? I
> also think it would be a good idea to wrap the compilers and the option
> to install them in the installer as this is where the MinGW installer
> will excel relative to the MSVC installer.
>
> Basically I know nothing above the NSI scripting language and avoided
> learning it, but it seems that the MSVC and MinGW packages will be so
> similar that the modifications in NSI for one or the other will be minimal.
>

Hmm, I also currently have never worked with nsi scripts. I took a quick
look at micheal's .nsi scripts in the repos and did not understand them
at first, so I have to do some learning.

I personally would have shamelessly extracted useful code from michael's
script and adapted for the mingw32 package.
I don't know which way is the easier:
  -) assuming that the msvc and mingw packages are similar, and adding
effort (every time) to every difference that occurs
  -) adding effort to have seperate msvc and mingw scripts, taking
advantage of michael's already available scripts

I tend to use the second option.

The packages are basically similar but there will be many different
details (at least currently) - this may change over time, who knows.
So I'd start with a rather simple installer with less options, only the
ATLAS part, and a full octave installation (no options there).
This can (and will) be improved over time.

benjamin


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Marco atzeri-3]

--- Tatsuro MATSUOKA ha scritto:

> Hello
Hi Tatsuro

>
> --- Marco Atzeri wrote:
>
> > > > - MSVC uses cruft.dll, MinGW uses libcruft.dll
> >
> > while for cygwin is cygcruft.dll
> >
> Really ? Simply building of octave on cygwin, it
> will be produced libcruft.dll, liboctave.dll and
> liboctinterp.dll.
>
> Did you change the name of the above dll files by
> yourself?
> For octave 2.1.xx on cygwin, libcruft.dll,
> liboctave.dll and liboctinterp.dll were used.
>
> Why  do you use the name like cygcruft.dll ?
> It will grateful for me you to explain the reason of
> file name changes.

that is the expected standard in cygwin to
differentiate cygwin from mingwn dll.

http://cygwin.com/cygwin-ug-net/dll.html

currently I only hacked the configure/makefile
to meet the cygwin standard for the porting
but I should wrote a more serius patch
to be merged in the mainstream.

> Regards
>
> Tatsuro
>

Regards
Marco



      Hai un indirizzo email difficile da ricordare?
Scegli quello che hai sempre desiderato su Yahoo! Mail
http://it.docs.yahoo.com/nuovo_indirizzo.html

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Tatsuro MATSUOKA-2]

Hello Marco

Thank you for your explanation.
I have understood the reason.

Regards

Tatsuro

--- Marco Atzeri <marco_atzeri@...> wrote:

> --- Tatsuro MATSUOKA ha scritto:
>
> > Hello
> Hi Tatsuro
>
> >
> > --- Marco Atzeri wrote:
> >
> > > > > - MSVC uses cruft.dll, MinGW uses libcruft.dll
> > >
> > > while for cygwin is cygcruft.dll
> > >
> > Really ? Simply building of octave on cygwin, it
> > will be produced libcruft.dll, liboctave.dll and
> > liboctinterp.dll.
> >
> > Did you change the name of the above dll files by
> > yourself?
> > For octave 2.1.xx on cygwin, libcruft.dll,
> > liboctave.dll and liboctinterp.dll were used.
> >
> > Why  do you use the name like cygcruft.dll ?
> > It will grateful for me you to explain the reason of
> > file name changes.
>
> that is the expected standard in cygwin to
> diffe