What generates disabledPlugins.c?

Ah, that leads me right to the problem. Thanks, Eliot!

OK, so first, the standard warning that I'm a clueless newbie, so please forgive any silly questions.

It looks like this is what happens: when you run configure, lines 27296 - 27362 check to see if you're building vm-sound-OSS. If not, that plugin's added to the variable disabled_plugins.

But later, lines 28696 - 28708 do the same thing. (Checkpoint 1)

Later on, that variable's turned into a file plugins.exc (for "except", I guess).

mktarget then builds a disabledPlugins.c with duplicate entries for those two plugins.

Going back to Checkpoint 1 above, configure itself looks like it's generated by something (autoconf?) from configure.ac, which has special cases for the Problem Plugins:

AC_ARG_WITH(vm-sound-OSS,
[  --without-vm-sound-OSS      disable OSS vm sound support default=enabled]],
 [with_vm_sound_OSS="$withval"],
 [with_vm_sound_OSS="yes"])
if test "$with_vm_sound_OSS"="no"; then
      AC_PLUGIN_DISABLE_PLUGIN(vm-sound-OSS);
fi

So this and the corresponding chunk for vm-display-fbdev must be commented out, and configure regenerated, and then presumably disabledPlugins.c won't have duplications.

Now I'm happy to do the legwork here, but I've never touched autoconf or m4 stuff in my life. Any hints would be greatly appreciated!

frank

On 2010/07/20 19:37, Eliot Miranda wrote:

platforms/unix/config/mktargets

e.g. find platforms -name .svn -print -o \( -type f \) -exec grep -H
disabledPlugins {} \; | fgrep -v .svn

which is useful enough to wrap up in a script (which I link to
$HOME/bin/findsvn $HOME/bin/findgit & $HOME/bin/findcvs, etc.

#!/bin/sh
#IFS=<tab><nl>
IFS='
'
DIR=.svn
case $0 in
*git)   DIR=.git;;
*cvs)   DIR=CVS;;
esac
DIRS=
while [ -n "$1" -a -d "$1" ]; do
        DIRS="$DIRS     $1"
        shift
done
find ${DIRS:-.} -name $DIR -prune -o \( "$@" \) | grep -v /$DIR

On Tue, Jul 20, 2010 at 1:29 AM, Frank Shearar

<[hidden email] <mailto:[hidden email]>> wrote:


   When I check out and build the latest VM on FreeBSD,
   disabledPlugins.c contains some duplicated definitions (reported in
   an earlier mail).

   I tried to find what generates that file in VMMaker, and failed.
   I've tried grepping the contents of the mcz, and can't find any
   mention of "disabled".

   (But as long as I say --without-npsqueak, and remove the offending
   duplications from disabledPlugins.c, the Cog VM compiled on FreeBSD!)

   frank

On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
>
> But the more serious issue is that the configure in VMMaker is only suitable
> for linux.  I guess that the right thing to do for FreeBSD is to run make in
> platforms/unix/config to generate a FreeBSD-specific configure.  But I'm out
> of my depth when it comes to autoconf.

Note that Ian moved to CMake for the unix builds, so autoconf is no longer
used for building from the SVN trunk. In addition, Geoffroy Couprie has
developed this further such that the VM can be built for both unix and
Windows targets, see thread here:

 http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html

It's up to Ian and Andreas to say if they want to pursue this direction,
but if you need the Cog build process to be more platform independent
this would be a good thing to consider.

Dave

On 7/22/2010 4:55 AM, David T. Lewis wrote:

On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:

But the more serious issue is that the configure in VMMaker is only suitable
for linux.  I guess that the right thing to do for FreeBSD is to run make in
platforms/unix/config to generate a FreeBSD-specific configure.  But I'm out
of my depth when it comes to autoconf.

Note that Ian moved to CMake for the unix builds, so autoconf is no longer
used for building from the SVN trunk. In addition, Geoffroy Couprie has
developed this further such that the VM can be built for both unix and
Windows targets, see thread here:

 http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html

It's up to Ian and Andreas to say if they want to pursue this direction,
but if you need the Cog build process to be more platform independent
this would be a good thing to consider.

Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
* Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue.

* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters.
* Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.

On the other hand, there are some exceptionally good reasons to use MSVC:
* Debugging: Did you know that MSVC now has seemless in-place editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
* Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.

* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.

At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.

On 7/22/2010 4:55 AM, David T. Lewis wrote:

On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:

But the more serious issue is that the configure in VMMaker is only suitable
for linux.  I guess that the right thing to do for FreeBSD is to run make in
platforms/unix/config to generate a FreeBSD-specific configure.  But I'm out
of my depth when it comes to autoconf.

Note that Ian moved to CMake for the unix builds, so autoconf is no longer
used for building from the SVN trunk. In addition, Geoffroy Couprie has
developed this further such that the VM can be built for both unix and
Windows targets, see thread here:

 http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html

It's up to Ian and Andreas to say if they want to pursue this direction,
but if you need the Cog build process to be more platform independent
this would be a good thing to consider.

Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
* Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue.
* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters.
* Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.

On the other hand, there are some exceptionally good reasons to use MSVC:
* Debugging: Did you know that MSVC now has seemless in-place editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
* Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.

At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.

Cheers,
 - Andreas

 
Hello,

On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab <[hidden email]> wrote:

On 7/22/2010 4:55 AM, David T. Lewis wrote:

On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:

But the more serious issue is that the configure in VMMaker is only suitable
for linux.  I guess that the right thing to do for FreeBSD is to run make in
platforms/unix/config to generate a FreeBSD-specific configure.  But I'm out
of my depth when it comes to autoconf.

Note that Ian moved to CMake for the unix builds, so autoconf is no longer
used for building from the SVN trunk. In addition, Geoffroy Couprie has
developed this further such that the VM can be built for both unix and
Windows targets, see thread here:

 http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html

It's up to Ian and Andreas to say if they want to pursue this direction,
but if you need the Cog build process to be more platform independent
this would be a good thing to consider.

Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
* Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue.

* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters.
* Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.

MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.

 

On the other hand, there are some exceptionally good reasons to use MSVC:
* Debugging: Did you know that MSVC now has seemless in-place editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
* Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.

Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?

 

* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.

At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.

 Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :)

I think it would still need to be fixed though, but that's less work to do.

Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.

Best regards,

Geoffroy

 
Hi Geoffroy,

On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie <[hidden email]> wrote:

 
Hello,

On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab <[hidden email]> wrote:

On 7/22/2010 4:55 AM, David T. Lewis wrote:

On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:

But the more serious issue is that the configure in VMMaker is only suitable
for linux.  I guess that the right thing to do for FreeBSD is to run make in
platforms/unix/config to generate a FreeBSD-specific configure.  But I'm out
of my depth when it comes to autoconf.

Note that Ian moved to CMake for the unix builds, so autoconf is no longer
used for building from the SVN trunk. In addition, Geoffroy Couprie has
developed this further such that the VM can be built for both unix and
Windows targets, see thread here:

 http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html

It's up to Ian and Andreas to say if they want to pursue this direction,
but if you need the Cog build process to be more platform independent
this would be a good thing to consider.

Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
* Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue.

* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters.
* Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.

 

MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.

What about C++ compilation?

 

 

On the other hand, there are some exceptionally good reasons to use MSVC:
* Debugging: Did you know that MSVC now has seemless in-place editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
* Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.

 

Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?

The thread info block TIB isn't provided, a hack is required to get multi-monitor stuff to compile against directx7, CommandLineToArgvW doesn't appear to compile correctly.  WS_ACTIVECAPTION is not defined.  STACK_SIZE_PARAM_IS_A_RESERVATION is not defined.  Some socket constants are not defined, etc, etc.  Look for references to __MINGW32__, !defined & ifndef in platforms/win32 in the Cog tree.  Not a lot current;y because we moved to cygwin and gcc 3.4.4, but when we were with the old 2.95 there was a lot more.  As far as we're aware gcc 2.95 still produces better code for the interpreter than either gcc 3.x or 4.x (although I suspect that one needs to declare global registers differently, i,e. prefix them with static, and things will be copacetic again).

 

* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.

At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.

 Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :)

I think it would still need to be fixed though, but that's less work to do.

Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.

Yes.  Its just a matter of ifdeffing, and the differences can be localized.  There are differences anyway.  Since MingW uses the MS libraries a few choice MS incompatibilities surface such as printf format specifiers for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d etc.  Hence

#if _MSC_VER

# define LLFMT "I64d"

#else

# define LLFMT "lld"

#endif

On 7/22/2010 10:34 AM, Geoffroy Couprie wrote:

   * Performance of the VM: With the JIT, the performance difference
   between the compilers no longer matters.
   * Size of difficulty of the install: New versions of MingW are no
   easier to install than Cygwin or other monsters.

MSYS is not that hard to install. And GCC can be use to cross compile,
which is really useful for tests, continuous integration, etc.

You can do all of this on Windows, we use Ant and Staf for such purposes.

   On the other hand, there are some exceptionally good reasons to use
   MSVC:
   * Debugging: Did you know that MSVC now has seemless in-place
   editing? When I worked on SqueakSSL, I was shocked to find that an
   access violation was simply presented as a break point and after
   fixing it the compiler patched the code in place without restarting
   Squeak, and it worked!
   * Up-to-date headers and libraries: SqueakSSL wouldn't compile on
   *any* version of MingW or Cygwin due to the absence / lack of
   correctness of the headers and missing libraries even though the
   APIs are 5+ years old.

Did you check the recent headers? Most of the recent API (XP/Vista) are
in the actual MinGW headers. The DirectX headers are a bit old, but
considering you're using DirectX 7, I don't think that's an issue. What
specific headers/libraries/functions are you talking about?

Try compiling SqueakSSL and see how far you get. But really, I'm just *tired* of hunting this stuff; I have lost all patience.

   * Consistent use of runtime libraries: For some external linkage,
   having the latest MSVC platform libraries available is important.

   At this point the advantage is clearly with the MS tool chain and
   the only hurdle is that I'll have to update all the makefiles etc.

 Well, here goes my shameless advertisement: CMake could be used to
generate Makefiles for MSVC :)

I'm not sure I understand. What point is there in "generating" Makefiles? I've never generated any Makefiles for my builds, why would an extra indirection be advantageous?

Anyway, do you think you could keep the code compatible with GCC? I
could take care of the header fixes.

I'm not planning on breaking anything that compiles today but I'll no longer go out of my way to provide compatibility with ancient headers and libraries. In other words, no more code like this:

#if _WIN32_WINNT < 0x0500 /* i.e., an old mingw */

static HRESULT (__stdcall *SHGetFolderPathW)(HWND, int, HANDLE, DWORD, WCHAR*);

#define CSIDL_APPDATA 0x001A
#define CSIDL_PROGRAM_FILES 0x0026
#define CSIDL_MYMUSIC 0x000D
#define CSIDL_MYPICTURES 0x0027
#define CSIDL_MYVIDEO 0x000E
#define CSIDL_PROFILE   40

#endif

/* ... */

#if _WIN32_WINNT < 0x0500 /* i.e. on old mingw */
 hShell = LoadLibrary("SHFolder.dll");
 SHGetFolderPathW = (void*)GetProcAddress(hShell, "SHGetFolderPathW");
#endif

 

On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda <[hidden email]> wrote:

 
Hi Geoffroy,

On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie <[hidden email]> wrote:

 
Hello,

On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab <[hidden email]> wrote:

On 7/22/2010 4:55 AM, David T. Lewis wrote:

On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:

But the more serious issue is that the configure in VMMaker is only suitable
for linux.  I guess that the right thing to do for FreeBSD is to run make in
platforms/unix/config to generate a FreeBSD-specific configure.  But I'm out
of my depth when it comes to autoconf.

Note that Ian moved to CMake for the unix builds, so autoconf is no longer
used for building from the SVN trunk. In addition, Geoffroy Couprie has
developed this further such that the VM can be built for both unix and
Windows targets, see thread here:

 http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html

It's up to Ian and Andreas to say if they want to pursue this direction,
but if you need the Cog build process to be more platform independent
this would be a good thing to consider.

Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
* Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue.

* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters.
* Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.

 

MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.

What about C++ compilation?

I don't know what issues you encountered, but 3.4.5 was fine, 4.2 had broken exception handling, and 4.4 works well.

On the other hand, there are some exceptionally good reasons to use MSVC:
* Debugging: Did you know that MSVC now has seemless in-place editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
* Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.

 

Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?

The thread info block TIB isn't provided, a hack is required to get multi-monitor stuff to compile against directx7, CommandLineToArgvW doesn't appear to compile correctly.  WS_ACTIVECAPTION is not defined.  STACK_SIZE_PARAM_IS_A_RESERVATION is not defined.  Some socket constants are not defined, etc, etc.  Look for references to __MINGW32__, !defined & ifndef in platforms/win32 in the Cog tree.  Not a lot current;y because we moved to cygwin and gcc 3.4.4, but when we were with the old 2.95 there was a lot more.  As far as we're aware gcc 2.95 still produces better code for the interpreter than either gcc 3.x or 4.x (although I suspect that one needs to declare global registers differently, i,e. prefix them with static, and things will be copacetic again).

Would it be hard to update the code to more recent directx versions? (do you have to maintain the code for old Windows versions?)

A lot of headers were fixed in recent MinGW versions (and as far as I know, squeak builds fine with gcc 4). I don't know gcc 2.95 (the version used when I learned C was 3.4.5 :p), and I can't judge the performance differences, but I think requiring gcc 4.4 would allow a lot of code cleaning.

 

 

* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.

At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.

 Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :)

I think it would still need to be fixed though, but that's less work to do.

Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.

Yes.  Its just a matter of ifdeffing, and the differences can be localized.  There are differences anyway.  Since MingW uses the MS libraries a few choice MS incompatibilities surface such as printf format specifiers for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d etc.  Hence

#if _MSC_VER

# define LLFMT "I64d"

#else

# define LLFMT "lld"

#endif

Yes, THAT is really annoying. We encountered a lot of problems with 32/64 code and format specifiers in vlc, but switching to gcc 4.4 fixed them.