Re: DTrace enabled build fails

/usr/sbin/dtrace -G -s utils/probes.d access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o -o utils/probes.o
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -L../../src/port -L/opt/csw/lib/ -Wl,-R'/export/home/pei/devel/pg-install/lib' access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o utils/probes.o ../../src/port/libpgport_srv.a -lrt -lsocket -lm -o postgres
Undefined first referenced
symbol in file
AbortTransaction utils/probes.o
CommitTransaction utils/probes.o
ld: fatal: Symbol referencing errors. No output written to postgres
collect2: ld returned 1 exit status
gmake: *** [postgres] Error 1

Does it not like static functions?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Does it not like static functions?

I seem to recall Robert mentioning that they'd only recently fixed
DTrace to cope with probes in static functions. Maybe you need to
get an update?

regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Does it not like static functions?
>
> I seem to recall Robert mentioning that they'd only recently fixed
> DTrace to cope with probes in static functions. Maybe you need to
> get an update?

That rings a bell. Can we get a more precise designation on what
version of DTrace we support? And where can one get that required
update?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

>That rings a bell. Can we get a more precise designation on what
>version of DTrace we support? And where can one get that required
>update?
>
>
>
Peter,

The problem with static function was fixed recently and is now available
in Solaris Express (the development version of Solaris). You can get the
bits from http://www.sun.com/software/solaris/solaris-express/get.jsp. I
forgot to mention this know issue in my previous emails!

I was told by the DTrace engineer that this fix will be in the next
update of Solaris 10.

Regards,
-Robert

Robert Lor wrote:
> Peter Eisentraut wrote:
>
> >That rings a bell. Can we get a more precise designation on what
> >version of DTrace we support? And where can one get that required
> >update?
> >
> >
> >
> Peter,
>
> The problem with static function was fixed recently and is now available
> in Solaris Express (the development version of Solaris). You can get the
> bits from http://www.sun.com/software/solaris/solaris-express/get.jsp. I
> forgot to mention this know issue in my previous emails!
>
> I was told by the DTrace engineer that this fix will be in the next
> update of Solaris 10.

Do we need to add detection logic to catch buggy versions?

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

>
>Do we need to add detection logic to catch buggy versions?
>
>
>
Instead of adding extra logic, I think it's sufficient with
documentation since the issue will soon be fixed in the next Solaris update.

Regards,
-Robert

Robert Lor <Robert(dot)Lor(at)Sun(dot)COM> writes:
> Bruce Momjian wrote:
>> Do we need to add detection logic to catch buggy versions?
>>
> Instead of adding extra logic, I think it's sufficient with
> documentation since the issue will soon be fixed in the next Solaris update.

I agree ... it's not like this is a feature aimed at novices.

regards, tom lane