Thread: self-fubar'ed? consistent make failures (undef'd symbols) on OSX ...

self-fubar'ed? consistent make failures (undef'd symbols) on OSX ...

From
OpenMacNews
Date:
(hmmm .. odd, this didn't make it b4 ... is there are a msg size limit on the
list?)

hi all,

i dunno if (yet) if this coincidence or not, but ...

since abt the time Dave had announced the commits integrating Florian's
patches, I'm no longer able to successfully 'make' pgadmin3 CVS HEAD on OSX.

after a successful build of wxWidgets-255 + StevenCsomor's patch, any/all
subsequent attempts to build pgadmin3 HEAD:

    /usr/ports/pgadmin-cvs
    unsetenv CFLAGS CPPFLAGS CXX CXXFLAGS LDFLAGS LDDLFLAGS LD_PREBIND LC_ALL LANG
LINGUAS
    setenv CPPFLAGS "-I/usr/local/ssl/include"
    setenv LDFLAGS "-L/usr/local/ssl/lib -lssl -lcrypto -L/usr/local/lib -lexpat
-lintl -lgettextlib -lpng -ljpeg -ltiff -lz"

    ./configure \
    --enable-appbundle \
    --enable-static \
    --disable-debug \
    --with-wx=/usr/local/wxWidgets-255 \
    --with-wx-config=wx-config \
    --with-pgsql=/usr/local/pgsql \
    --with-pgsql-include=/usr/local/pgsql/include

    make all

are resulting in a make failure after scads of undef'd symbol errors (cref
output below)

i've monkeyed w/ the usual assortment of discrete CPPFLAGS & LDFLAGS
assignments, $PATH vars etc, tried both static & shared builds, all to no avail.

the thing is, i *had* this working the other day, but have (?) clearly fubar'ed
something ...

any suggestions would be appreciated -- i'm slowly going nuts over here.  has
something chnged when i wasn't looking?  $$$ sez i'm doing sumthin dumb ...

thx,

richard




...
if g++ -DHAVE_CONFIG_H -I. -I. -I..  -Wall -g -I../src/include
-I../src/agent/include -I../src/slony/include -I/usr/local/ssl/include
-I/usr/local/pgsql/include -DSSL
-I/usr/local/wxWidgets-255/lib/wx/include/mac-unicode-release-static-2.5
-I/usr/local/wxWidgets-255/include/wx-2.5 -D__WXMAC__ -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES -DNO_GCC_PRAGMA   -I/usr/local/wxWidgets-255/include/wx-2.5
-no-cpp-precomp -fno-rtti -Wall -g -I../src/include -I../src/agent/include
-I../src/slony/include -Wall -g -O0 -MT dlgRepSubscription.o -MD -MP -MF
".deps/dlgRepSubscription.Tpo" -c -o dlgRepSubscription.o `test -f
'./slony/dlgRepSubscription.cpp' || echo './'`./slony/dlgRepSubscription.cpp; \
then mv -f ".deps/dlgRepSubscription.Tpo" ".deps/dlgRepSubscription.Po"; else
rm -f ".deps/dlgRepSubscription.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H -I. -I. -I..  -Wall -g -I../src/include
-I../src/agent/include -I../src/slony/include -I/usr/local/ssl/include
-I/usr/local/pgsql/include -DSSL
-I/usr/local/wxWidgets-255/lib/wx/include/mac-unicode-release-static-2.5
-I/usr/local/wxWidgets-255/include/wx-2.5 -D__WXMAC__ -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES -DNO_GCC_PRAGMA   -I/usr/local/wxWidgets-255/include/wx-2.5
-no-cpp-precomp -fno-rtti -Wall -g -I../src/include -I../src/agent/include
-I../src/slony/include -Wall -g -O0 -MT slFunctions.o -MD -MP -MF
".deps/slFunctions.Tpo" -c -o slFunctions.o `test -f './slony/slFunctions.cpp'
|| echo './'`./slony/slFunctions.cpp; \
then mv -f ".deps/slFunctions.Tpo" ".deps/slFunctions.Po"; else rm -f
".deps/slFunctions.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H -I. -I. -I..  -Wall -g -I../src/include
-I../src/agent/include -I../src/slony/include -I/usr/local/ssl/include
-I/usr/local/pgsql/include -DSSL
-I/usr/local/wxWidgets-255/lib/wx/include/mac-unicode-release-static-2.5
-I/usr/local/wxWidgets-255/include/wx-2.5 -D__WXMAC__ -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES -DNO_GCC_PRAGMA   -I/usr/local/wxWidgets-255/include/wx-2.5
-no-cpp-precomp -fno-rtti -Wall -g -I../src/include -I../src/agent/include
-I../src/slony/include -Wall -g -O0 -MT explainCanvas.o -MD -MP -MF
".deps/explainCanvas.Tpo" -c -o explainCanvas.o `test -f
'./ui/explainCanvas.cpp' || echo './'`./ui/explainCanvas.cpp; \
then mv -f ".deps/explainCanvas.Tpo" ".deps/explainCanvas.Po"; else rm -f
".deps/explainCanvas.Tpo"; exit 1; fi
ui/explainCanvas.cpp: In member function `void
   ExplainCanvas::SetExplainString(const wxString&)':
ui/explainCanvas.cpp:94: warning: initialization to `int' from `double'
...
<BIG snip>
...
wxMemoryFSHandlerBase::FindFirst(wxString const&, int)
wxMemoryFSHandlerBase::wxMemoryFSHandlerBase()
wxMemoryFSHandlerBase::~wxMemoryFSHandlerBase()
wxFileSystemHandler::GetClassInfo() const
vtable for wxFileSystem
make[2]: *** [pgadmin3] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


Re: self-fubar'ed? consistent make failures (undef'd symbols) on OSX ...

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of OpenMacNews
> Sent: 14 April 2005 02:43
> To: pgadmin-hackers
> Subject: [pgadmin-hackers] self-fubar'ed? consistent make
> failures (undef'd symbols) on OSX ...
>
> (hmmm .. odd, this didn't make it b4 ... is there are a msg
> size limit on the
> list?)

Yeah - 30K or something like that.

> hi all,
>
> i dunno if (yet) if this coincidence or not, but ...
>
> since abt the time Dave had announced the commits integrating
> Florian's
> patches, I'm no longer able to successfully 'make' pgadmin3
> CVS HEAD on OSX.

Unless it failed in any of the agent code (for which I also committed an
update at that time) I doubt it's a code problem.

> after a successful build of wxWidgets-255 + StevenCsomor's
> patch, any/all
> subsequent attempts to build pgadmin3 HEAD:

Did you build the OGL lib from the wx contrib dir? The build system
probably doesn't check for that like it does for stc (Andreas only added
it recently, and I don't think he updated the autoconf stuff).

Regards, Dave.

Re: self-fubar'ed? consistent make failures (undef'd

From
"Florian G. Pflug"
Date:
OpenMacNews wrote:
> ok, so now i'm confused ...
>
> given the make failures i was seeing earlier, i decided to backtrack &
> turn all debugging options ON.
>
> i rebuilt wxwidgets with debug ON, and then attempted to build pgadmin3
> cvs again ... and it worked w/o error.
>
> ??? huh ???
>
> rewind ... repeat  --> same thing
>
> i.e.
>
> case A) wxwidgets (disable-debug) --> pgadmin3 (disable- OR
> enable-debug), MAKE failure
> case B) wxwidgets (enable-debug) --> pgadmin3 (disable- OR
> enable-debug), MAKE ok
>
> so, QUESTION:
>
>     why is the pgadmin3 'make' seemingly dependent on wxwidgets' DEBUG =
> on?
I just found out why:
When compiled with debug, the wx-libs are named e.g libwx_macud,
when compiled without, they are named libwx_macu.

The wx-configure check in acinclude.m4 detects wx in both cases,
but doesn't actually add the wx-libs to the list of to-be-linked-to
libs in the second case.

I'm in the process of fixing this - expect a patch later today.

greetings, Florian Pflug

Attachment

Re: self-fubar'ed? consistent make failures (undef'd symbols) on OSX ...

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of Dave Page
> Sent: 14 April 2005 08:36
> To: OpenMacNews; pgadmin-hackers
> Subject: Re: [pgadmin-hackers] self-fubar'ed? consistent make
> failures (undef'd symbols) on OSX ...
>
> Did you build the OGL lib from the wx contrib dir? The build system
> probably doesn't check for that like it does for stc (Andreas
> only added
> it recently, and I don't think he updated the autoconf stuff).

My apologies - he did update it.

Regards, Dave

Re: self-fubar'ed? consistent make failures (undef'd

From
OpenMacNews
Date:
hi,

>> since abt the time Dave had announced the commits integrating
>> Florian's
>> patches, I'm no longer able to successfully 'make' pgadmin3
>> CVS HEAD on OSX.
>
> Unless it failed in any of the agent code (for which I also committed an
> update at that time) I doubt it's a code problem.

per other posts, turns out this was due to a dependence on wxwidgets needing to
be built w/ --enable-debug

>> after a successful build of wxWidgets-255 + StevenCsomor's
>> patch, any/all
>> subsequent attempts to build pgadmin3 HEAD:
>
> Did you build the OGL lib from the wx contrib dir? The build system
> probably doesn't check for that like it does for stc (Andreas only added
> it recently, and I don't think he updated the autoconf stuff).

yes, i've built both the reqts: STC & OGL

cheers,

richard

Re: self-fubar'ed? consistent make failures (undef'd

From
OpenMacNews
Date:
hi there,

-- On April 14, 2005 2:05:49 PM +0200  "Florian G. Pflug" <fgp@phlo.org> wrote:
> Hm... "touch a; mv a A" works on both macs that I have access too....
> (Funnily enough, you can just repeat the move, it always succeeds, e.g.
> "touch a; mv a A; mv a A")

really?  i've tried this on all my macs, and 'no go'.  i always see

    % touch a
    % mv a A
        mv: `a' and `A' are the same file
    % mv a A2
    % mv A2 A

odd.

is there a setting somewhere abt this?  who knew?

>>     why is the pgadmin3 'make' seemingly dependent on wxwidgets' DEBUG =
>> on?
> I just found out why:
> When compiled with debug, the wx-libs are named e.g libwx_macud,
> when compiled without, they are named libwx_macu.
>
> The wx-configure check in acinclude.m4 detects wx in both cases,
> but doesn't actually add the wx-libs to the list of to-be-linked-to
> libs in the second case.
>
> I'm in the process of fixing this - expect a patch later today.

great!  i missed that completely ...


cheers,

richard

Re: self-fubar'ed? consistent make failures (undef'd

From
"Florian G. Pflug"
Date:
OpenMacNews wrote:
> -- On April 14, 2005 2:05:49 PM +0200  "Florian G. Pflug" <fgp@phlo.org>
> wrote:
>
>> Hm... "touch a; mv a A" works on both macs that I have access too....
>> (Funnily enough, you can just repeat the move, it always succeeds, e.g.
>> "touch a; mv a A; mv a A")
>
> really?  i've tried this on all my macs, and 'no go'.  i always see
>
>    % touch a
>    % mv a A
>        mv: `a' and `A' are the same file
>    % mv a A2
>    % mv A2 A
>
> odd.
>
> is there a setting somewhere abt this?  who knew?
Which Version of OSX are you using? Is your harddisk formatted
as UFS or HFS+?

>>>     why is the pgadmin3 'make' seemingly dependent on wxwidgets' DEBUG =
>>> on?
>>
>> I just found out why:
>> When compiled with debug, the wx-libs are named e.g libwx_macud,
>> when compiled without, they are named libwx_macu.
>>
>> The wx-configure check in acinclude.m4 detects wx in both cases,
>> but doesn't actually add the wx-libs to the list of to-be-linked-to
>> libs in the second case.
>>
>> I'm in the process of fixing this - expect a patch later today.
>
> great!  i missed that completely ...
Dave applied two patches from me today, and additionally
added some wx 2.6 support on his own ;-)

I believe it should work with wx CVS out-of-the-box now - or - at least
compile. It still crashed when opening a dialog when using wx CVS for  me,
so if you don't intent to hunt that bug down, stay with 2.5.5 + fix ;-)

greetings, Florian Pflug

Attachment

Re: self-fubar'ed? consistent make failures (undef'd

From
OpenMacNews
Date:
hi,

> Which Version of OSX are you using? Is your harddisk formatted
> as UFS or HFS+?

OSX 10.3.8, fully updated

% uname -a
Darwin devbox 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec 22 14:26:17 PST 2004;
root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC  Power Macintosh powerpc


> Dave applied two patches from me today, and additionally
> added some wx 2.6 support on his own ;-)

great.  i'll be trying it a little later after a wx 2.5.5 retry

> I believe it should work with wx CVS out-of-the-box now - or - at least
> compile. It still crashed when opening a dialog when using wx CVS for  me,
> so if you don't intent to hunt that bug down, stay with 2.5.5 + fix ;-)

i'll try get to both ...

cheers,

richard

Re: self-fubar'ed? consistent make failures (undef'd

From
OpenMacNews
Date:
oops, missed one ...

> Which Version of OSX are you using? Is your harddisk formatted
> as UFS or HFS+?

HFS+ in all cases ...

richard