[PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)

[Hans-Christoph Steiner]

On Apr 24, 2009, at 3:20 PM, Bryan Jurish wrote:

> moin Hans, moin list,
>
> On 2009-04-20 02:10:17, Hans-Christoph Steiner <hans at eds.org>  
> appears to
> have written:
>> On Apr 19, 2009, at 5:22 AM, Bryan Jurish wrote:
>>> moin Hans,
>>> On 2009-04-18 06:57:53, Hans-Christoph Steiner <hans at eds.org>  
>>> appears to
>>> have written:
>>>>
>>>> The bad news is that it seems that my bad diagnosis led you on a  
>>>> wide
>>>> goose chase thru the pain of Windows development.
>>>
>>> It may or may not have been a bad diagnosis (although it certainly  
>>> was a
>>> pain ;-) -- I still haven't verified the former, since I don't use  
>>> (or
>>> understand) all of the auto-build scripts.  I'm still kinda hoping
>>> IOhannes might make some headway there...
>>
>> You don't really need to understand the auto-build scripts, all that
>> needs to work is this:
>>
>> cd pure-data/externals
>> make moocow
>> make moocow_install
>
> yup, I've understood that bit (and the motivations, I think).  I meant
> that since the problems arising in 'make moocow' appear to have been
> *due to* clever & fiendish details of earlier scripts (e.g. use of  
> rsync
> rather than svn, the cygwin/mingw dichotomy, etc. etc.), it would have
> behooved me to have understood those scripts better (e.g. at all)...
>
>>>> Apparently,
>>>> string2any and friends are still not getting built.  In fact all  
>>>> of the
>>>> 'moocow' is empty on Windows.
>
> This is still stumping me.  The win32 build farm machine's  
> config.log is
> showing me (for externals/moocow/locale):
>
> configure:2701: gcc \
> -DPD -O2 -mcpu=i586 -mtune=pentium3 \
> -I/home/pd/auto-build/pd-extended/pd/src \
> -Wall -W -ggdb \
> -I/home/pd/auto-build/pd-extended/Gem/src \
> -mms-bitfields \
> -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \
> -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' \
> -L/home/pd/auto-build/pd-extended/pd/bin \
> conftest.c >&5
> <command line>:4:1: macro names must be identifiers
> <command line>:5:1: macro names must be identifiers
> <command line>:6:1: macro names must be identifiers
> <command line>:7:1: macro names must be identifiers
> configure:2704: $? = 1
> configure:2742: result:
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME "locale"
> | #define PACKAGE_TARNAME "locale"
> | #define PACKAGE_VERSION "0.02-1"
> | #define PACKAGE_STRING "locale 0.02-1"
> | #define PACKAGE_BUGREPORT "moocow at ling.uni-potsdam.de"
> | #define PACKAGE "locale"
> | #define VERSION "0.02-1"
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:2749: error: C compiler cannot create executables
>
> ... newline escapes in the gcc call added post-hoc for legibility.   
> The
> above call works fine (creating a.exe) by hand on the build farm win32
> machine with "/cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin"  
> prepended
> to PATH, so I can't grok where things might be going wrong, much less
> what the "macro names must be identifiers" errors are all about --
> assumedly some of the '-D' flags are giving me grief, but since I  
> can't
> reproduce the error, I can't tell which ones or what to do about it.
>
> Anyone have any ideas?


Here's the trick: in the MSYS shell, where Pd is being built, / 
cygdrive/c/MinGW  is actually mounted as /usr/local, so you want to  
use /usr/local/bin, etc.  Usually autotools does that by default  
though, AFAIK.


> I can't use rdesktop currently, since it's telling me I'd have to kick
> out another user (pd).

Oops, sorry, that was me.  In the future, feel free to kick out the  
user if it has been more than an hour or so.

.hc

>>> In a related question, should the auto-build process for the win32
>>> build-farm machine be trying to build everything from the  
>>> LIB_TARGETS
>>> variable in externals/Makefile?  If so, then I must be being pretty
>>> dense, because I can't see where my builds are getting called (I see
>>> install calls, but no configuration or compilation), much less where
>>> they might be failing...
>>
>> You are correct.  Search for 'moocow_install:' in externals/Makefile.
>> That's where its being called.
>
> Yes, right; but I couldn't see (until the rsync fix/hack was applied)
> where the 'moocow' target was getting called, thus recursing into
> externals/moocow/extended.  That's showing up now, so no worries.
>
> marmosets,
> 	Bryan
>
> -- 
> Bryan Jurish                           "There is *always* one more  
> bug."
> jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic  
> Entomology
>



----------------------------------------------------------------------------

If nature has made any one thing less susceptible than all others of  
exclusive property, it is the action of the thinking power called an  
idea, which an individual may exclusively possess as long as he keeps  
it to himself; but the moment it is divulged, it forces itself into  
the possession of everyone, and the receiver cannot dispossess himself  
of it.            - Thomas Jefferson