From: David A. <da...@us...> - 2008-01-29 22:04:55
|
All - I have been working on the build process for ooRexx today. The goal of = all of this is to be able to compile ooRexx on Windows using the *nix build= utilities under Cygwin on Windows. I did some experimenting earlier thi= s week and discovered a really simple method of using the *nix build utilities under Cygwin to build ooRexx using the standard Microsoft compiler and SDK (no gcc, no cygwin.dll needed). All this work is in preparation for performing this type of build. As a by product I have fixed one or two items as well. Here is what I h= ave accomplished so far. - The Makefile.am file has been heavily modified and there are more modifications coming. - The oorexx.spec.in file has been modified. - Installing the samples on *nix only partially works. I intend to fix this. - The distribution tar and zip files now contain all the samples (yeah!= ). - Some simple changes to configure.ac have been made to support Windows= . Right now I am only concentration on the *nix build but all of the chan= ges are for making everting platform independent. After I get the *nix chan= ges in I will start on the Windows changes. Mark - I will really need your help in getting the Windows stuff correc= t and of course a lot of testing will need to be done to determine that a= ll this works :-) Thanks, W. David Ashley IBM Systems and Technology Group Lab Services Open Object Rexx Team Mobile Phone: 512-289-7506= |
From: Mark M. <mie...@gm...> - 2008-01-30 01:21:20
|
On Jan 29, 2008 1:27 PM, David Ashley <da...@us...> wrote: > I have been working on the build process for ooRexx today. I've watched your progress in the commits. > Mark - I will really need your help in getting the Windows stuff correct and > of course a lot of testing will need to be done to determine that all this > works :-) I will of course help. But, I'm less than enthused about it. <grin> I don't have any strong reasons why this won't work, but for me it is inconvenient. I build on 5 or 6 different Windows systems. None of them have cygwin on them. I don't like using cygwin on Windows. I use the GnuWin32 tools for all the unix utilities I am fond of. Like grep, cat, rm, sed, tail, head, etc. So, it is just one more thing I'll have to install and maintain on a bunch of systems that really adds no value to the systems. As I implied, I don't really have any strong objections, it's just that it adds one layer to what anyone that wants to try building on Windows has to cope with. I think the majority of people that want to build on Windows are comfortable with the Windows tools. Microsoft now makes everything needed to build ooRexx for yourself available for free. And everything uses the Windows paradigm, which everyone that is on Windows is comfortable with. -- Mark Miesfeld |
From: Rick M. <obj...@gm...> - 2008-01-30 10:31:23
|
Mike, What David has proposed does not build a cygwin executable, it just uses the cygwin ports of the tools (autoconf, et al) to manage the make files and dependencies. Right now, our build is split into two worlds (Windows/other). The windows build has no real depedency tracking and is a clunky combination of batch files and make files. Much of the time, one is force to just wipe the build and recompile everything from scratch. In the non-Windows world, autoconf does a very nice job of generating the header file dependencies for us and is generally easier to deal with when build updates need to be made. Granted, I'm generally the one who is impacted by this the most, but not having to update too radically different builds every time a new source file is added would make my life so much easier. Rick On Jan 30, 2008 3:23 AM, Mike Cowlishaw <MF...@uk...> wrote: > Mark wrote: > > > I will of course help. But, I'm less than enthused about it. <grin> > > > > I don't have any strong reasons why this won't work, but for me it is > > inconvenient. > > > > I build on 5 or 6 different Windows systems. None of them have cygwin > > on them. I don't like using cygwin on Windows. I use the GnuWin32 > > tools for all the unix utilities I am fond of. Like grep, cat, rm, > > sed, tail, head, etc. So, it is just one more thing I'll have to > > install and maintain on a bunch of systems that really adds no value > > to the systems. > > And, as I mentioned, cygwin actually removes value, because it usurps a > whole pile of Windows commands (of which the most obvious is DIR; another > is LINK, which breaks MS compiles & builds). And you cannot build > stand-alone .exes with it (there's a hack which is supposed to let you do > that, but I never got it to work). > > Definitely best avoided. > > Mike > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Mike C. <MF...@uk...> - 2008-01-30 10:45:46
|
> What David has proposed does not build a cygwin executable, it just > uses the cygwin ports of the tools (autoconf, et al) to manage the > make files and dependencies. Right now, our build is split into two > worlds (Windows/other). The windows build has no real depedency > tracking and is a clunky combination of batch files and make files. > Much of the time, one is force to just wipe the build and recompile > everything from scratch. > > In the non-Windows world, autoconf does a very nice job of > generating the header file dependencies for us and is generally > easier to deal with when build updates need to be made. Granted, > I'm generally the one who is impacted by this the most, but not > having to update too radically different builds every time a new > source file is added would make my life so much easier. OK, I was concerned that the ooRexx setup .exe would require cygwin1.dll. Yes, up to you guys entirely if that's not the case -- I don't see myself doing an ooRexx Windows build (though I've had to do a couple on obscure Linuxii :-)). Mike > On Jan 30, 2008 3:23 AM, Mike Cowlishaw <MF...@uk...> wrote: > Mark wrote: > > > I will of course help. But, I'm less than enthused about it. <grin> > > > > I don't have any strong reasons why this won't work, but for me it is > > inconvenient. > > > > I build on 5 or 6 different Windows systems. None of them have cygwin > > on them. I don't like using cygwin on Windows. I use the GnuWin32 > > tools for all the unix utilities I am fond of. Like grep, cat, rm, > > sed, tail, head, etc. So, it is just one more thing I'll have to > > install and maintain on a bunch of systems that really adds no value > > to the systems. > And, as I mentioned, cygwin actually removes value, because it usurps a > whole pile of Windows commands (of which the most obvious is DIR; another > is LINK, which breaks MS compiles & builds). And you cannot build > stand-alone .exes with it (there's a hack which is supposed to let you do > that, but I never got it to work). > > Definitely best avoided. > > Mike > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
From: Mark M. <mie...@gm...> - 2008-01-30 15:37:14
|
On Jan 30, 2008 7:01 AM, Rick McGuire <obj...@gm...> wrote: > David, > > Does the make need to be invoked inside the cygwin shell in order to run, or > can you do the build by invoking the cygwin make utility outside the shell? > I believe Mark and I both like to use the SlickEdit build facility to run > the build inside of SlickEdit to take advantage of the "Next Compile Error" > feature of the tooling. Aha, you hit upon the biggest reason for my reservations. I do everything in SlickEdit and at a Windows console prompt. The way I work on Windows doesn't seem to integrate well with cyqwin. I just hated to say don't go down this path because the tools *I* use don't work well with cygwin. It seemed awfully selfish. <grin> I've been through this before with the original ppc405 chips. IBM used cygwin to compile the evaluation software for the product line. It was a real headache for me. And not just for me, everyone on the development team hated it. We do everything on Linux now. -- Mark Miesfeld |
From: Chip D. <ch...@av...> - 2008-01-30 04:24:48
|
On 1/30/08 01:21 Mark Miesfeld said: > On Jan 29, 2008 1:27 PM, David Ashley <da...@us...> wrote: > >> Mark - I will really need your help in getting the Windows stuff correct... > > I will of course help. But, I'm less than enthused about it. <grin> Isn't this just another manifestation of the native-features-vs.-cross-platform debate that came up recently in the GUI-builder discussion? There is great value to having a single builder for all platforms on which ooRexx runs, but less value if that entails installing Yet-Another-Builder to do so. If I've got to install another package first, why not just write the whole thing in Rexx and require me to install Regina? At least that has an extrinsic value to a Rexx programmer on any platform. And I'm sure Mark meant that "everything [on Windows] uses the Windows paradigm" and not that AIX (say) has capitulated to doing it the Windows Way. It has already been suggested that all ooRexx platforms now support Java. Why is that not a viable approach? -Chip- |
From: Mark M. <mie...@gm...> - 2008-01-30 05:14:08
|
On Jan 29, 2008 8:24 PM, Chip Davis <ch...@av...> wrote: > And I'm sure Mark meant that "everything [on Windows] uses the Windows paradigm" > and not that AIX (say) has capitulated to doing it the Windows Way. Yes what I meant with: "Microsoft now makes everything needed to build ooRexx for yourself available for free. And everything uses the Windows paradigm, which everyone that is on Windows is comfortable with." Was that Microsoft now has free versions of all the tools needed to build ooRexx, and all those Microsoft tools use the Windows paradigm. -- Mark Miesfeld |
From: Mike C. <MF...@uk...> - 2008-01-30 08:23:43
|
Mark wrote: > I will of course help. But, I'm less than enthused about it. <grin> > > I don't have any strong reasons why this won't work, but for me it is > inconvenient. > > I build on 5 or 6 different Windows systems. None of them have cygwin > on them. I don't like using cygwin on Windows. I use the GnuWin32 > tools for all the unix utilities I am fond of. Like grep, cat, rm, > sed, tail, head, etc. So, it is just one more thing I'll have to > install and maintain on a bunch of systems that really adds no value > to the systems. And, as I mentioned, cygwin actually removes value, because it usurps a whole pile of Windows commands (of which the most obvious is DIR; another is LINK, which breaks MS compiles & builds). And you cannot build stand-alone .exes with it (there's a hack which is supposed to let you do that, but I never got it to work). Definitely best avoided. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
From: Rick M. <obj...@gm...> - 2008-01-30 12:39:25
|
Mark, Is it possible that what David is doing will work with either the cygwin tool set or the GnuWin32 versions? I'm not particularly tied to using cygwin....I just want a unified build process and make files. Rick On Jan 29, 2008 8:21 PM, Mark Miesfeld <mie...@gm...> wrote: > On Jan 29, 2008 1:27 PM, David Ashley <da...@us...> wrote: > > > I have been working on the build process for ooRexx today. > > I've watched your progress in the commits. > > > Mark - I will really need your help in getting the Windows stuff correct > and > > of course a lot of testing will need to be done to determine that all > this > > works :-) > > I will of course help. But, I'm less than enthused about it. <grin> > > I don't have any strong reasons why this won't work, but for me it is > inconvenient. > > I build on 5 or 6 different Windows systems. None of them have cygwin > on them. I don't like using cygwin on Windows. I use the GnuWin32 > tools for all the unix utilities I am fond of. Like grep, cat, rm, > sed, tail, head, etc. So, it is just one more thing I'll have to > install and maintain on a bunch of systems that really adds no value > to the systems. > > As I implied, I don't really have any strong objections, it's just > that it adds one layer to what anyone that wants to try building on > Windows has to cope with. I think the majority of people that want to > build on Windows are comfortable with the Windows tools. Microsoft > now makes everything needed to build ooRexx for yourself available for > free. And everything uses the Windows paradigm, which everyone that > is on Windows is comfortable with. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Mark M. <mie...@gm...> - 2008-01-30 13:49:50
|
On Jan 30, 2008 4:39 AM, Rick McGuire <obj...@gm...> wrote: > Mark, > > Is it possible that what David is doing will work with either the cygwin > tool set or the GnuWin32 versions? I'm not particularly tied to using > cygwin....I just want a unified build process and make files. It is possible, I'm not sure. I don't think the autoconf stuff with the GnuWin32 versions works. Actually it may not even be there. If it was only a matter of having a make file that used tools like rm, mkdir, and cat, etc., it would work with GnuWin32. I don't think the autoconf stuff will work, have to see. Don't get me wrong, I am much in favor of getting ride of the current .bat file driven Windows build. But, I liked the nmake Windows build on the 4.0 stuff. I understand that it would be nice to have only one thing to update when a new file was added or deleted. Maybe you could just update the unix side and assign updating the Windows nmake side to me. Sort of like how you assign a bug to Lee for inclusion in the change log. <grin> Just kidding of course. -- Mark Miesfeld |
From: Rick M. <obj...@gm...> - 2008-01-30 13:59:28
|
The downside to the nmake-based make files in the 4.0 build is the header file dependency management is a completely manual process....and the initial setup didn't take into account any include file nesting, but rather just picked up what the modules happened to be directly including at the time. The autoconf process generates the dependency lists automatically, which gives us a cleaner, more reliable build. If there are some native windows tools available that can allow that step to be automated, then I'm guess I'd be ok with that too. Rick On Jan 30, 2008 8:49 AM, Mark Miesfeld <mie...@gm...> wrote: > On Jan 30, 2008 4:39 AM, Rick McGuire <obj...@gm...> wrote: > > > Mark, > > > > Is it possible that what David is doing will work with either the cygwin > > tool set or the GnuWin32 versions? I'm not particularly tied to using > > cygwin....I just want a unified build process and make files. > > It is possible, I'm not sure. I don't think the autoconf stuff with > the GnuWin32 versions works. Actually it may not even be there. If > it was only a matter of having a make file that used tools like rm, > mkdir, and cat, etc., it would work with GnuWin32. I don't think the > autoconf stuff will work, have to see. > > Don't get me wrong, I am much in favor of getting ride of the current > .bat file driven Windows build. But, I liked the nmake Windows build > on the 4.0 stuff. > > I understand that it would be nice to have only one thing to update > when a new file was added or deleted. Maybe you could just update the > unix side and assign updating the Windows nmake side to me. Sort of > like how you assign a bug to Lee for inclusion in the change log. > <grin> Just kidding of course. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: David A. <da...@us...> - 2008-01-30 14:49:39
|
All - I think I had better provide a few more details of just what I expect t= he Cygwin environment to look like. Earlier this week I tried an experiment. First I installed Cygwin with = ONLY the following options: - autoconf - automake - libtool Note that gcc was NOT installed. I also added the contents of the Visual Studio setvars.bat file to the = top of the cygwin.bat file so that Cygwin would have complete access to the= Visual Studio environment. I then created a small Hello World program and set up an autoconf.ac an= d Makefile.am files for it. What I wanted to find out was whether or not = the autotools could discover the VC++7 compiler whithout any special direct= ives in the Makefile.am or the autoconf.ac files. And to my amazement they c= ould be found and used! I successfully compiled my Hello World program and i= t ran without the cygwin.dll file! After looking closer I discovered the although libtool was was install = (and invoked by the bootstrap script) all of the libtool statements in the generated Makefile were commented out and replaced with calls to cl.exe= which in turn invoked the Microsoft linker. So libtool is required only= because it is invoked by the bootstrap script and is not used after tha= t. What all this means is that it is possible to have a single build mecha= nism that operates the same on all platforms and uses the native compiler an= d linker to that platform. Of course, the configure.ac will need a few changes and the Makefiles.a= m file will need a LOT of changes to make all this work. But I can handle= that. What I currently doing is making the Makefile.am file detect the difference between different platforms (Unix vs Windows). The last two commits I made go a long way towards accomplishing that goal. I am not there yet as I have not added any Windows specific stuff to those files= . I am getting the unix stuff completely set up prior to tackling the Windo= ws stuff. And just to be contrary (that is my nature :-) ) I believe that if you = are going to use the GNUtils you might as well use Cygwin. Either way you h= ave to download a bunch of stuff and the GNUtils have the disadvantage of running as native Windows applications without all the support mechanis= ms offered by a default Cygwin environment. And once you get the Cygwin se= tup on one Windows box it is easily zipped up and transported to another machine since it requires no registry entries or environment variables.= There is one other point I want to make as well. Over the last few year= s I have seen some open source applications that appeared to use just this mechanism to build their Windows applications. I always wondered how th= ey accomplished that and I believe now I understand how they did it. So th= is build mechanism for Windows must be used by a lot of other open source projects. We would not be the only one using this mechanism. Thanks, W. David Ashley IBM Systems and Technology Group Lab Services Open Object Rexx Team Mobile Phone: 512-289-7506= |
From: Rick M. <obj...@gm...> - 2008-01-30 15:01:38
|
David, Does the make need to be invoked inside the cygwin shell in order to run, or can you do the build by invoking the cygwin make utility outside the shell? I believe Mark and I both like to use the SlickEdit build facility to run the build inside of SlickEdit to take advantage of the "Next Compile Error" feature of the tooling. The cygwin shell can be invoked in the SlickEdit build window, but it doesn't handle the special characters used for color switching very well. If the cygin shell is required, is there a mode where you can invoke the cygwin batch file to run a single command? Rick On Jan 30, 2008 9:41 AM, David Ashley <da...@us...> wrote: > All - > > I think I had better provide a few more details of just what I expect the > Cygwin environment to look like. > > Earlier this week I tried an experiment. First I installed Cygwin with > ONLY the following options: > > - autoconf > - automake > - libtool > > Note that gcc was NOT installed. > > I also added the contents of the Visual Studio setvars.bat file to the top > of the cygwin.bat file so that Cygwin would have complete access to the > Visual Studio environment. > > I then created a small Hello World program and set up an autoconf.ac and > Makefile.am files for it. What I wanted to find out was whether or not the > autotools could discover the VC++7 compiler whithout any special directives > in the Makefile.am or the autoconf.ac files. And to my amazement they > could be found and used! I successfully compiled my Hello World program and > it ran without the cygwin.dll file! > > After looking closer I discovered the although libtool was was install > (and invoked by the bootstrap script) all of the libtool statements in the > generated Makefile were commented out and replaced with calls to cl.exewhich in turn invoked the Microsoft linker. So libtool is required only > because it is invoked by the bootstrap script and is not used after that. > > What all this means is that it is possible to have a single build > mechanism that operates the same on all platforms and uses the native > compiler and linker to that platform. > > Of course, the configure.ac will need a few changes and the Makefiles.amfile will need a LOT of changes to make all this work. But I can handle > that. What I currently doing is making the Makefile.am file detect the > difference between different platforms (Unix vs Windows). The last two > commits I made go a long way towards accomplishing that goal. I am not there > yet as I have not added any Windows specific stuff to those files. I am > getting the unix stuff completely set up prior to tackling the Windows > stuff. > > And just to be contrary (that is my nature :-) ) I believe that if you are > going to use the GNUtils you might as well use Cygwin. Either way you have > to download a bunch of stuff and the GNUtils have the disadvantage of > running as native Windows applications without all the support mechanisms > offered by a default Cygwin environment. And once you get the Cygwin setup > on one Windows box it is easily zipped up and transported to another machine > since it requires no registry entries or environment variables. > > There is one other point I want to make as well. Over the last few years I > have seen some open source applications that appeared to use just this > mechanism to build their Windows applications. I always wondered how they > accomplished that and I believe now I understand how they did it. So this > build mechanism for Windows must be used by a lot of other open source > projects. We would not be the only one using this mechanism. > > > Thanks, > W. David Ashley > IBM Systems and Technology Group Lab Services > Open Object Rexx Team > Mobile Phone: 512-289-7506 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: <rvj...@xs...> - 2008-01-30 19:42:07
|
Hi David, in the meantime, the current 3.x trunk gives me this message on the =20 running of every exec: *E* Unable to load library: libREXXUTIL.dylib ! Error message: dlopen(libREXXUTIL.dylib, 2): Symbol not found: =20 __Z13SysInitializev Referenced from: /opt/ooRexx/lib/ooRexx/libREXXUTIL.dylib Expected in: flat namespace Did something change (the casing of the library name?) best regards, Ren=E9 Jansen. On 30 jan 2008, at 15:41, David Ashley wrote: > All - > > I think I had better provide a few more details of just what I =20 > expect the Cygwin environment to look like. > |
From: Rick M. <obj...@gm...> - 2008-01-30 19:48:30
|
That looks like it is my fault. I took some code and move it into the common code tree. The code was common between Windows and unix except for the case of "rexxutil". I'm surprised this even built on Linux. Rick On Jan 30, 2008 2:42 PM, Ren=E9 Jansen <rvj...@xs...> wrote: > Hi David, > > in the meantime, the current 3.x trunk gives me this message on the > running of every exec: > > *E* Unable to load library: libREXXUTIL.dylib ! > Error message: dlopen(libREXXUTIL.dylib, 2): Symbol not found: > __Z13SysInitializev > Referenced from: /opt/ooRexx/lib/ooRexx/libREXXUTIL.dylib > Expected in: flat namespace > > Did something change (the casing of the library name?) > > best regards, > > Ren=E9 Jansen. > > > On 30 jan 2008, at 15:41, David Ashley wrote: > > > All - > > > > I think I had better provide a few more details of just what I > > expect the Cygwin environment to look like. > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: <rvj...@xs...> - 2008-01-30 21:59:10
|
Hi Rick, I see something's changed, but it gives me nearly the same error: Total bytes for this image 727404 bytes *E* Unable to load library: librexxutil.dylib ! Error message: dlopen(librexxutil.dylib, 2): Symbol not found: =20 __Z13SysInitializev Referenced from: /Users/rvjansen/apps/oorexx/interpreter-3.x/=20 trunk/./.libs/librexxutil.dylib Expected in: flat namespace best regards, Ren=E9. On 30 jan 2008, at 20:47, Rick McGuire wrote: > That looks like it is my fault. I took some code and move it into =20 > the common code tree. The code was common between Windows and unix =20= > except for the case of "rexxutil". I'm surprised this even built on =20= > Linux. > > Rick > > On Jan 30, 2008 2:42 PM, Ren=E9 Jansen <rvj...@xs...> wrote: > Hi David, > > in the meantime, the current 3.x trunk gives me this message on the > running of every exec: > > *E* Unable to load library: libREXXUTIL.dylib ! > Error message: dlopen(libREXXUTIL.dylib, 2): Symbol not found: > __Z13SysInitializev > Referenced from: /opt/ooRexx/lib/ooRexx/libREXXUTIL.dylib > Expected in: flat namespace > > Did something change (the casing of the library name?) > > best regards, > > Ren=E9 Jansen. > > > On 30 jan 2008, at 15:41, David Ashley wrote: > > > All - > > > > I think I had better provide a few more details of just what I > > expect the Cygwin environment to look like. > > > > > = ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > = ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > = http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/___________________= ____________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |