(Posting this again because I forgot to subscribe to the list, and I don''t know if the mail is delivered in those conditions. Sorry if this is a double post.) Hi all, so I spoke to Luis a few hours ago on IRC, because I was having problems building ruby on windows using the new installer scripts. While I''m happy to report that it now compiles flawlessly since the update to the last MinGW version, I still have a problem installing any gem, because it can''t find zlib: "No such file to load -- zlib". I checked and zlib1.dll is in the ruby_mingw/bin directory, and I have that in my path. Any suggestions, other than "ditch Vista?" Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20080410/c7d935c0/attachment-0001.html
On Thu, Apr 10, 2008 at 7:33 AM, David Leal <dgleal at gmail.com> wrote:> (Posting this again because I forgot to subscribe to the list, and I don''t > know if the mail is delivered in those conditions. Sorry if this is a double > post.) >No double post, it seems it didn''t made through :-P> Hi all, > > so I spoke to Luis a few hours ago on IRC, because I was having problems > building ruby on windows using the new installer scripts. While I''m happy to > report that it now compiles flawlessly since the update to the last MinGW > version, I still have a problem installing any gem, because it can''t find > zlib: "No such file to load -- zlib". I checked and zlib1.dll is in the > ruby_mingw/bin directory, and I have that in my path. >Fir of all, thank you for your interest and the time you took to report this. I''m glad the update "partially" worked :-) It seems that building of zlib extension failed. you can check if the extension got build in ruby_build/ext/zlib (look for mkmf.log and leftovers like .o files). If none of these things exists (or even the folder), could be the root of the problem. This will sound silly, but can you try cleanup and try again?>rake clean(wait until sandbox is wiped)>rake(that should extract and compile everything from scratch, again). You could see it also if it gets build during this phase, the extension is the last to be build, check of the output after "compiling zlib" (expected output): compiling zlib make[1]: Entering directory `/d/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_build/ext/zlib'' gcc -I. -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -DHAVE_ZLIB_H -DOS_CODE=OS_WIN32 -g -O2 -c ../../../ruby_1_8/ext/zlib/zlib.c gcc -shared -s -o ../../.ext/i386-mingw32/zlib.so zlib.o -L. -L../.. -L. -Wl,--enable-auto-image-base,--enable-auto-import,--export-all -lmsvcrt-ruby18 -lzdll -lshell32 -lws2_32 make[1]: Leaving directory `/d/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_build/ext/zlib''> Any suggestions, other than "ditch Vista?" >You wouldn''t hear me say something like that, never :-P> Cheers, > > David >Please let me know if that helped and report any other issues, I''ll happily hack in solutions for this :-) Regards, -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
On Thu, Apr 10, 2008 at 1:13 PM, Luis Lavena <luislavena at gmail.com> wrote:> Fir of all, thank you for your interest and the time you took to > report this. I''m glad the update "partially" worked :-):) Actually, thank you for all your work and patience. Working with Ruby in Windows is a nightmare right now, I''m glad you''re set to change that.> It seems that building of zlib extension failed. you can check if the > extension got build in ruby_build/ext/zlib (look for mkmf.log and > leftovers like .o files).Ok, I recompiled everything and got the same thing. There is a mkmf.log, which I''m pasting below. I hope it helps. have_library: checking for deflateReset() in -lz... -------------------- no "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -lz -lws2_32 " conftest.c: In function `t'': conftest.c:6: error: `deflateReset'' undeclared (first use in this function) conftest.c:6: error: (Each undeclared identifier is reported only once conftest.c:6: error: for each function it appears in.) checked program was: /* begin */ 1: #include <windows.h> 2: #include <winsock.h> 3: 4: /*top*/ 5: int main() { return 0; } 6: int t() { void ((*volatile p)()); p = (void ((*)()))deflateReset; return 0; } /* end */ "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -lz -lws2_32 " \mingw\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lz collect2: ld returned 1 exit status checked program was: /* begin */ 1: /*top*/ 2: int main() { return 0; } 3: int t() { deflateReset(); return 0; } /* end */ -------------------- have_library: checking for deflateReset() in -llibz... -------------------- no "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -llibz -lws2_32 " conftest.c: In function `t'': conftest.c:6: error: `deflateReset'' undeclared (first use in this function) conftest.c:6: error: (Each undeclared identifier is reported only once conftest.c:6: error: for each function it appears in.) checked program was: /* begin */ 1: #include <windows.h> 2: #include <winsock.h> 3: 4: /*top*/ 5: int main() { return 0; } 6: int t() { void ((*volatile p)()); p = (void ((*)()))deflateReset; return 0; } /* end */ "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -llibz -lws2_32 " \mingw\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibz collect2: ld returned 1 exit status checked program was: /* begin */ 1: /*top*/ 2: int main() { return 0; } 3: int t() { deflateReset(); return 0; } /* end */ -------------------- have_library: checking for deflateReset() in -lzlib... -------------------- no "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -lzlib -lws2_32 " conftest.c: In function `t'': conftest.c:6: error: `deflateReset'' undeclared (first use in this function) conftest.c:6: error: (Each undeclared identifier is reported only once conftest.c:6: error: for each function it appears in.) checked program was: /* begin */ 1: #include <windows.h> 2: #include <winsock.h> 3: 4: /*top*/ 5: int main() { return 0; } 6: int t() { void ((*volatile p)()); p = (void ((*)()))deflateReset; return 0; } /* end */ "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -lzlib -lws2_32 " \mingw\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lzlib collect2: ld returned 1 exit status checked program was: /* begin */ 1: /*top*/ 2: int main() { return 0; } 3: int t() { deflateReset(); return 0; } /* end */ -------------------- have_library: checking for deflateReset() in -lzdll... -------------------- no "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -lzdll -lws2_32 " conftest.c: In function `t'': conftest.c:6: error: `deflateReset'' undeclared (first use in this function) conftest.c:6: error: (Each undeclared identifier is reported only once conftest.c:6: error: for each function it appears in.) checked program was: /* begin */ 1: #include <windows.h> 2: #include <winsock.h> 3: 4: /*top*/ 5: int main() { return 0; } 6: int t() { void ((*volatile p)()); p = (void ((*)()))deflateReset; return 0; } /* end */ "gcc -o conftest -I../.. -I../../../ruby_1_8 -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. -lmsvcrt-ruby18-static -lzdll -lws2_32 " \mingw\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lzdll collect2: ld returned 1 exit status checked program was: /* begin */ 1: /*top*/ 2: int main() { return 0; } 3: int t() { deflateReset(); return 0; } /* end */ -------------------- So it seems lzdll cannot be found, but it''s there, inside extract_utils and inside mingw/bin.Could this be another Vista related bug in mingw? Again, thanks for your work, Luis. Cheers, David
On Thu, Apr 10, 2008 at 12:35 PM, David Leal <dgleal at gmail.com> wrote:> > Ok, I recompiled everything and got the same thing. There is a > mkmf.log, which I''m pasting below. I hope it helps. > > have_library: checking for deflateReset() in -lz... -------------------- no > > "gcc -o conftest -I../.. -I../../../ruby_1_8 > -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. > -lmsvcrt-ruby18-static -lz -lws2_32 " > conftest.c: In function `t'': > conftest.c:6: error: `deflateReset'' undeclared (first use in this function) > conftest.c:6: error: (Each undeclared identifier is reported only once > conftest.c:6: error: for each function it appears in.) > checked program was: > /* begin */ > 1: #include <windows.h> > 2: #include <winsock.h> > 3: > 4: /*top*/ > 5: int main() { return 0; } > 6: int t() { void ((*volatile p)()); p = (void ((*)()))deflateReset; return 0; } > /* end */ >I only can point one difference between the build process in XP compared to Vista and is the library lookup paths passed into ld: -L"." -L"../.." versus the one I got: -L. -L../.. that is naive, but is the only difference I spot and is significant. Can you share with me the PATH and drive where you extracted the recipes? I''m just curious why it is quoting library (lib) lookup paths. Please let me know about this or contact me via gtalk so we can workout a solution. -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
Hi Luis, here''s my path: C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\ATI Technologies\ATI.ACE;C:\Program Files\Git\cmd;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Bazaar;C:\Program Files\Subversion\bin;c:\Utils\jruby-1.1\bin;C:\Program Files\Java\jdk1.6.0_05\bin;C:\Program Files\Mercurial;c:\utils\ruby\bin I''m building this on c:\Users\David\Development\ruby-installer I tried to do this using jruby (jruby -S rake ...) but the result is the same. I also found out that the problem is not only with zlib. Openssl doesn''t build also, neither does readline, and I''m pretty sure that every extension that depends on an external lib has this problem. rbconfig is generated with the LIBPATHFLAGS option set to "-L\"%s\"", but I can''t figure out where that is coming from. Cheers, David On Fri, Apr 11, 2008 at 1:11 AM, Luis Lavena <luislavena at gmail.com> wrote:> On Thu, Apr 10, 2008 at 12:35 PM, David Leal <dgleal at gmail.com> wrote: > > > > Ok, I recompiled everything and got the same thing. There is a > > mkmf.log, which I''m pasting below. I hope it helps. > > > > have_library: checking for deflateReset() in -lz... -------------------- no > > > > "gcc -o conftest -I../.. -I../../../ruby_1_8 > > -I../../../ruby_1_8/ext/zlib -g -O2 conftest.c -L"." -L"../.." -L. > > -lmsvcrt-ruby18-static -lz -lws2_32 " > > conftest.c: In function `t'': > > conftest.c:6: error: `deflateReset'' undeclared (first use in this function) > > conftest.c:6: error: (Each undeclared identifier is reported only once > > conftest.c:6: error: for each function it appears in.) > > checked program was: > > /* begin */ > > 1: #include <windows.h> > > 2: #include <winsock.h> > > 3: > > 4: /*top*/ > > 5: int main() { return 0; } > > 6: int t() { void ((*volatile p)()); p = (void ((*)()))deflateReset; return 0; } > > /* end */ > > > > I only can point one difference between the build process in XP > compared to Vista and is the library lookup paths passed into ld: > > -L"." -L"../.." > > versus the one I got: > > -L. -L../.. > > that is naive, but is the only difference I spot and is significant. > > Can you share with me the PATH and drive where you extracted the recipes? > > I''m just curious why it is quoting library (lib) lookup paths. > > Please let me know about this or contact me via gtalk so we can > workout a solution. > > > -- > Luis Lavena > Multimedia systems > - > Human beings, who are almost unique in having the ability to learn from > the experience of others, are also remarkable for their apparent > disinclination to do so. > Douglas Adams > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel >
On Fri, Apr 11, 2008 at 6:49 AM, David Leal <dgleal at gmail.com> wrote:> Hi Luis, > > here''s my path: > > C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program > Files\ATI Technologies\ATI.ACE;C:\Program > Files\Git\cmd;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program > Files\Bazaar;C:\Program > Files\Subversion\bin;c:\Utils\jruby-1.1\bin;C:\Program > Files\Java\jdk1.6.0_05\bin;C:\Program > Files\Mercurial;c:\utils\ruby\bin > > I''m building this on c:\Users\David\Development\ruby-installer >Wow, too weird... I can say is the first time I see something like this :-) Just for the sake of testing, can you move c:\utils\ruby\bin on top of the path? SET PATH=c:\utils\ruby\bin;%PATH% I know that sounds stupid (not silly), but what to exhaust all these issues before restore my notebook vista and give a whirl in there :-P> I tried to do this using jruby (jruby -S rake ...) but the result is > the same. I also found out that the problem is not only with zlib. > Openssl doesn''t build also, neither does readline, and I''m pretty sure > that every extension that depends on an external lib has this problem. > rbconfig is generated with the LIBPATHFLAGS option set to "-L\"%s\"", > but I can''t figure out where that is coming from. >That is taken from the generated config.h file in ruby_build Just run configure step by its own and peek what ended in there (of course, on a clean sandbox and after extract and prepare).> Cheers, >Thank you David, I''ll see what can do to workaround this the weekend. Sorry the inconvenience. In the meantime you can grab a pre-build package from my dump server: http://dump.mmediasys.com/installer3 Regards, -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
On 4/11/08, Luis Lavena <luislavena at gmail.com> wrote:> Just for the sake of testing, can you move c:\utils\ruby\bin on top of the path?Oh, I did that already. The ruby entry used to be the first in the path, but I changed it to see if that''s what was causing the troubles.> Just run configure step by its own and peek what ended in there (of > course, on a clean sandbox and after extract and prepare).I sent you an email with all the files inside ruby_build. I hope it helps.> Thank you David, I''ll see what can do to workaround this the weekend. > Sorry the inconvenience.No need to apologize. You''re doing a great favor to us all. We''re the ones in debt to you.> In the meantime you can grab a pre-build package from my dump server: > > http://dump.mmediasys.com/installer3Thanks, I''ll do that. Cheers, David
On Fri, Apr 11, 2008 at 7:01 PM, David Leal <dgleal at gmail.com> wrote:> On 4/11/08, Luis Lavena <luislavena at gmail.com> wrote: > > > Just run configure step by its own and peek what ended in there (of > > course, on a clean sandbox and after extract and prepare). > > I sent you an email with all the files inside ruby_build. I hope it helps. >Yes, it helped and I think I spotted where the problem lies. Based on the files, it appears you updated the autoconf package (from 2.59 to 2.61). That is correct? "generated by GNU Autoconf 2.61." that is part of the config.log file. I sticked to 2.59 since the new set of files generated by 2.61 didn''t worked properly. config.log (2.59): LIBPATHFLAG='' -L%s'' your config.log (2.61): LIBPATHFLAG='' -L"%s"'' Somehow, dunno from where, the newer version of autoconf is being called. The only one I see from your path that could be doing that is Git, even more precise if you have a .bashrc file in your HOME folder that is altering the $PATH... Try running msys.bat from sandbox/msys and ''which autoconf'' and it should point to /bin/autoconf (7,663 bytes) and check the version information around line 130 of that file. Please let me know how it ended. -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
On Sat, Apr 12, 2008 at 2:32 AM, Luis Lavena <luislavena at gmail.com> wrote:> Based on the files, it appears you updated the autoconf package (from > 2.59 to 2.61). That is correct? > > "generated by GNU Autoconf 2.61."If you look at the ruby-1.8.6-p114.tar.gz, the configure file inside already says generated by autoconf 2.61, so I think the problem lies there. Anyway, I cleared my PATH, only leaving c:\Windows, c:\Windows\System32 and c:\Windows\System32\Wbem. It still says that the files were generated by autoconf 2.61. The msys autoconf is version 2.59. Deleting configure, running autoconf and then running rake configure doesn''t help. I''m thinking that there''s something else I should do, but I don''t know what. What do you think, Luis? Thanks, David
On Sat, Apr 12, 2008 at 10:51 AM, David Leal <dgleal at gmail.com> wrote:> On Sat, Apr 12, 2008 at 2:32 AM, Luis Lavena <luislavena at gmail.com> wrote: > > Based on the files, it appears you updated the autoconf package (from > > 2.59 to 2.61). That is correct? > > > > "generated by GNU Autoconf 2.61." > > If you look at the ruby-1.8.6-p114.tar.gz, the configure file inside > already says generated by autoconf 2.61, so I think the problem lies > there. >Let me try running from the source file, since I was using checkout mode (rake CHECKOUT=1) to workaround a series of bugs related to Readline and pooling (eat your cpu) and rubygems too. Updating the recipes for RubyGems 1.1.1 and trying again right now :-)> Anyway, I cleared my PATH, only leaving c:\Windows, > c:\Windows\System32 and c:\Windows\System32\Wbem. It still says that > the files were generated by autoconf 2.61. The msys autoconf is > version 2.59. >It seems the problems lies in the values generated by autoconf 2.61 compared to the ones form 2.59. Since I was running form source, been always generating the configure script with autoconf, so didn''t found that until you exposed it. (which is good, give me enough arguments to scream at ruby-core list) :-)> Deleting configure, running autoconf and then running rake configure > doesn''t help. I''m thinking that there''s something else I should do, > but I don''t know what. > > What do you think, Luis? >Working on it, will post a followup in a few minutes. -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
On Sat, Apr 12, 2008 at 12:21 PM, Luis Lavena <luislavena at gmail.com> wrote:> > Let me try running from the source file, since I was using checkout > mode (rake CHECKOUT=1) to workaround a series of bugs related to > Readline and pooling (eat your cpu) and rubygems too. > > Updating the recipes for RubyGems 1.1.1 and trying again right now :-) >Ok, it worked in this end. even with the included configure script generated in 2.61, it works. (openssl get build, zlib too). So I guess is related to Vista now. Can you try the "rake CHECKOUT=1" build instead (you need to have subversion on the path) and send me your results? Based on that I''ll know how to deal with this issue. Please apologize all the inconveniences and my request of testing :-) Regards, -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
On 12/04/2008, Luis Lavena <luislavena at gmail.com> wrote:> On Fri, Apr 11, 2008 at 7:01 PM, David Leal <dgleal at gmail.com> wrote: > > On 4/11/08, Luis Lavena <luislavena at gmail.com> wrote: > > > > > > Just run configure step by its own and peek what ended in there (of > > > course, on a clean sandbox and after extract and prepare). > > > > I sent you an email with all the files inside ruby_build. I hope it helps. > > > > > Yes, it helped and I think I spotted where the problem lies. > > Based on the files, it appears you updated the autoconf package (from > 2.59 to 2.61). That is correct? > > "generated by GNU Autoconf 2.61." > > that is part of the config.log file. > > I sticked to 2.59 since the new set of files generated by 2.61 didn''t > worked properly. > > config.log (2.59): > > LIBPATHFLAG='' -L%s'' > > your config.log (2.61): > > LIBPATHFLAG='' -L"%s"'' > > Somehow, dunno from where, the newer version of autoconf is being > called. The only one I see from your path that could be doing that is > Git, even more precise if you have a .bashrc file in your HOME folder > that is altering the $PATH... > > Try running msys.bat from sandbox/msys and ''which autoconf'' and it > should point to /bin/autoconf (7,663 bytes) and check the version > information around line 130 of that file. >Did you find a solution? I patched configure.in on OS X to remove the quotes. There are similar linking problems as on Vista so I hope I would get rid of them this way. Looks like the shipped configure has LIBPATHFLAG with the quotes, though. Thanks Michal -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.diff Type: application/octet-stream Size: 272 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20080418/f09ceb83/attachment.obj
On Fri, Apr 18, 2008 at 12:16 PM, Michal Suchanek <hramrach at centrum.cz> wrote:> On 12/04/2008, Luis Lavena <luislavena at gmail.com> wrote: > > On Fri, Apr 11, 2008 at 7:01 PM, David Leal <dgleal at gmail.com> wrote: > > > On 4/11/08, Luis Lavena <luislavena at gmail.com> wrote: > > > > > > > > > Just run configure step by its own and peek what ended in there (of > > > > course, on a clean sandbox and after extract and prepare). > > > > > > I sent you an email with all the files inside ruby_build. I hope it helps. > > > > > > > > > Yes, it helped and I think I spotted where the problem lies. > > > > Based on the files, it appears you updated the autoconf package (from > > 2.59 to 2.61). That is correct? > > > > "generated by GNU Autoconf 2.61." > > > > that is part of the config.log file. > > > > I sticked to 2.59 since the new set of files generated by 2.61 didn''t > > worked properly. > > > > config.log (2.59): > > > > LIBPATHFLAG='' -L%s'' > > > > your config.log (2.61): > > > > LIBPATHFLAG='' -L"%s"'' > > > > Somehow, dunno from where, the newer version of autoconf is being > > called. The only one I see from your path that could be doing that is > > Git, even more precise if you have a .bashrc file in your HOME folder > > that is altering the $PATH... > > > > Try running msys.bat from sandbox/msys and ''which autoconf'' and it > > should point to /bin/autoconf (7,663 bytes) and check the version > > information around line 130 of that file. > > > > Did you find a solution? >After all it seems is not related to quoted paths, but a GCC problem on Vista: http://sourceforge.net/mailarchive/message.php?msg_name=4808B254.9000403%40tdragon.net http://sourceforge.net/mailarchive/message.php?msg_name=4808B667.584B9FC9%40dessent.net I''m trying to report these problems back to MinGW developers since we (one-click project) don''t have enough resources to run GCC compilation besides ruby one :-D> I patched configure.in on OS X to remove the quotes. There are similar > linking problems as on Vista so I hope I would get rid of them this > way. >Done that, didn''t work, it seems that even small things like a gcc hello world is broken on Vista. Will keep working on getting things properly for it, since without the One-Click Developer Kit will be useless.> Looks like the shipped configure has LIBPATHFLAG with the quotes, though. >Is because they used autconf 2.61, older versions (2.58 AFAIK) didn''t do that.> Thanks >Thanks to you for your interest, -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams