Re: Re: PATCH: The linker complains about the '-bundle_loader "../../src/backend/postgres"' against PostgreSQL 8.4 on OSX

Hi Heikki,

With PostgreSQL 8.4.11, I still face the same issue, resolved as part of
the following checked-in:
http://git.postgresql.org/gitweb/?p=pldebugger.git;a=commitdiff;h=b9c756ef6cd4bdabea203905b2071d0e6b4e0d4d

I tried to resolve the issue by removing the duplicate words for the
SHLIB_LINK variable in the Makefile for pldebugger.
I just changed it specifically for PostgreSQL 8.4 on OSX platform, because
PostgreSQL build script may get changed in future releases (i.e. pldebugger
is compiling well with PostgreSQL 9.0+ on OSX because of such modification.)

Please find the attached patch for the same.
I know - it looks ugly, but I could not think of any other solution at the
moment.

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com>

*http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>

On 30.04.2012 15:14, Ashesh Vashi wrote:
> With PostgreSQL 8.4.11, I still face the same issue, resolved as part of
> the following checked-in:
> http://git.postgresql.org/gitweb/?p=pldebugger.git;a=commitdiff;h=b9c756ef6cd4bdabea203905b2071d0e6b4e0d4d
>
> I tried to resolve the issue by removing the duplicate words for the
> SHLIB_LINK variable in the Makefile for pldebugger.
> I just changed it specifically for PostgreSQL 8.4 on OSX platform, because
> PostgreSQL build script may get changed in future releases (i.e. pldebugger
> is compiling well with PostgreSQL 9.0+ on OSX because of such modification.)
>
> Please find the attached patch for the same.
> I know - it looks ugly, but I could not think of any other solution at the
> moment.

Hmm, we have to currently jump through a lot of hoops to make the
Makefile do what we want. First of all, we're building two libraries
from the same Makefile. The usual PGXS targets don't support that, so I
had to hack it so that we use the MODULES variable to buld pldbgapi.so,
and in addition to that, set NAME=plugin_debugger and include
src/Makefile.shlib to build plugin_debugger.so.

Things would be much simpler if we had a separate subdirectory for
building plgdbgapi.so and plugin_debugger.so. However, it would be even
simpler if we just built it all into a single library. At the moment,
there's a runtime dependency between pldbgapi.so and plugin_debugger.so
anyway, so that to use any of the functions in pldbgapi.so, you have to
load plugin_debugger.so. If they were just one library, you could more
easily do local debugging without having to add plugin_debugger.so to
shared_preload_libraries. At the moment you get an error about a missing
symbol if you try to do that, unless you manually LOAD plugin_debugger.so.

Another unusual thing we do is that we install plugin_debugger.so to the
<installdir>/lib/plugins directory, instead of just <installdir>/lib.
We've had to add special install and uninstall rules for that.

To make that more straightforward, I think we should just install
plugin_debugger.so into lib like any other extension. I don't see any
particular reason why it has to be installed to plugins-directory.

Putting those two together, let's build just a single .so file, called
plugin_debugger.so, which contains both the PL/pgSQL hooks and the
client-facing pldbg_* functions used to do debugging. After that, the
makefile will be much simpler, which means less trouble with OS-specific
things like this. Not only now, but also in the future if the pgxs
makefiles are changed - we make quite a few assumptions of the pgxs
build system at the moment.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Thu, May 3, 2012 at 2:23 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 30.04.2012 15:14, Ashesh Vashi wrote:
>>
>> With PostgreSQL 8.4.11, I still face the same issue, resolved as part of
>> the following checked-in:
>>
>> http://git.postgresql.org/gitweb/?p=pldebugger.git;a=commitdiff;h=b9c756ef6cd4bdabea203905b2071d0e6b4e0d4d
>>
>> I tried to resolve the issue by removing the duplicate words for the
>> SHLIB_LINK variable in the Makefile for pldebugger.
>> I just changed it specifically for PostgreSQL 8.4 on OSX platform, because
>> PostgreSQL build script may get changed in future releases (i.e.
>> pldebugger
>> is compiling well with PostgreSQL 9.0+ on OSX because of such
>> modification.)
>>
>> Please find the attached patch for the same.
>> I know - it looks ugly, but I could not think of any other solution at the
>> moment.
>
>
> Hmm, we have to currently jump through a lot of hoops to make the Makefile
> do what we want. First of all, we're building two libraries from the same
> Makefile. The usual PGXS targets don't support that, so I had to hack it so
> that we use the MODULES variable to buld pldbgapi.so, and in addition to
> that, set NAME=plugin_debugger and include src/Makefile.shlib to build
> plugin_debugger.so.
>
> Things would be much simpler if we had a separate subdirectory for building
> plgdbgapi.so and plugin_debugger.so. However, it would be even simpler if we
> just built it all into a single library. At the moment, there's a runtime
> dependency between pldbgapi.so and plugin_debugger.so anyway, so that to use
> any of the functions in pldbgapi.so, you have to load plugin_debugger.so. If
> they were just one library, you could more easily do local debugging without
> having to add plugin_debugger.so to shared_preload_libraries. At the moment
> you get an error about a missing symbol if you try to do that, unless you
> manually LOAD plugin_debugger.so.
>
> Another unusual thing we do is that we install plugin_debugger.so to the
> <installdir>/lib/plugins directory, instead of just <installdir>/lib. We've
> had to add special install and uninstall rules for that.
>
> To make that more straightforward, I think we should just install
> plugin_debugger.so into lib like any other extension. I don't see any
> particular reason why it has to be installed to plugins-directory.
>
> Putting those two together, let's build just a single .so file, called
> plugin_debugger.so, which contains both the PL/pgSQL hooks and the
> client-facing pldbg_* functions used to do debugging. After that, the
> makefile will be much simpler, which means less trouble with OS-specific
> things like this. Not only now, but also in the future if the pgxs makefiles
> are changed - we make quite a few assumptions of the pgxs build system at
> the moment.

Sounds fine - but I'm not keen on making such changes in the back
branches. Can we fix the current problem, and re-architect for 9.2
please?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 06.05.2012 19:05, Dave Page wrote:
> On Thu, May 3, 2012 at 2:23 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> On 30.04.2012 15:14, Ashesh Vashi wrote:
>>>
>>> With PostgreSQL 8.4.11, I still face the same issue, resolved as part of
>>> the following checked-in:
>>>
>>> http://git.postgresql.org/gitweb/?p=pldebugger.git;a=commitdiff;h=b9c756ef6cd4bdabea203905b2071d0e6b4e0d4d
>>>
>>> I tried to resolve the issue by removing the duplicate words for the
>>> SHLIB_LINK variable in the Makefile for pldebugger.
>>> I just changed it specifically for PostgreSQL 8.4 on OSX platform, because
>>> PostgreSQL build script may get changed in future releases (i.e.
>>> pldebugger
>>> is compiling well with PostgreSQL 9.0+ on OSX because of such
>>> modification.)
>>>
>>> Please find the attached patch for the same.
>>> I know - it looks ugly, but I could not think of any other solution at the
>>> moment.
>>
>>
>> Hmm, we have to currently jump through a lot of hoops to make the Makefile
>> do what we want. First of all, we're building two libraries from the same
>> Makefile. The usual PGXS targets don't support that, so I had to hack it so
>> that we use the MODULES variable to buld pldbgapi.so, and in addition to
>> that, set NAME=plugin_debugger and include src/Makefile.shlib to build
>> plugin_debugger.so.
>>
>> Things would be much simpler if we had a separate subdirectory for building
>> plgdbgapi.so and plugin_debugger.so. However, it would be even simpler if we
>> just built it all into a single library. At the moment, there's a runtime
>> dependency between pldbgapi.so and plugin_debugger.so anyway, so that to use
>> any of the functions in pldbgapi.so, you have to load plugin_debugger.so. If
>> they were just one library, you could more easily do local debugging without
>> having to add plugin_debugger.so to shared_preload_libraries. At the moment
>> you get an error about a missing symbol if you try to do that, unless you
>> manually LOAD plugin_debugger.so.
>>
>> Another unusual thing we do is that we install plugin_debugger.so to the
>> <installdir>/lib/plugins directory, instead of just<installdir>/lib. We've
>> had to add special install and uninstall rules for that.
>>
>> To make that more straightforward, I think we should just install
>> plugin_debugger.so into lib like any other extension. I don't see any
>> particular reason why it has to be installed to plugins-directory.
>>
>> Putting those two together, let's build just a single .so file, called
>> plugin_debugger.so, which contains both the PL/pgSQL hooks and the
>> client-facing pldbg_* functions used to do debugging. After that, the
>> makefile will be much simpler, which means less trouble with OS-specific
>> things like this. Not only now, but also in the future if the pgxs makefiles
>> are changed - we make quite a few assumptions of the pgxs build system at
>> the moment.
>
> Sounds fine - but I'm not keen on making such changes in the back
> branches. Can we fix the current problem, and re-architect for 9.2
> please?

We don't really have back-branches for pldebugger. Or versioned
releases, for that matter. I'll fix this in git master. I consider the
current tip of the old CVS repository (or the corresponding checkout
from the git repo) to be the latest stable release, PostgreSQL one-click
installers <= 9.1 can continue to use that version.

We probably should tag and put out a versioned release of pldebugger on
pgxn, sometime during the PostgreSQL 9.2 beta period, so that it's ready
when PostgreSQL 9.2 is released.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Mon, May 7, 2012 at 11:33 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 06.05.2012 19:05, Dave Page wrote:
>>
>> Sounds fine - but I'm not keen on making such changes in the back
>> branches. Can we fix the current problem, and re-architect for 9.2
>> please?
>
>
> We don't really have back-branches for pldebugger. Or versioned releases,

Right - that's because it's only had minor bug fixes until now.

> for that matter. I'll fix this in git master. I consider the current tip of
> the old CVS repository (or the corresponding checkout from the git repo) to
> be the latest stable release, PostgreSQL one-click installers <= 9.1 can
> continue to use that version.

Can you create a "PRE-9_2" branch for the current architecture, and
apply Ashesh's patch to that if you think it's a reasonable fix
please? We can then move the older builds to that branch. Then the 9.2
changes can go on master.

> We probably should tag and put out a versioned release of pldebugger on
> pgxn, sometime during the PostgreSQL 9.2 beta period, so that it's ready
> when PostgreSQL 9.2 is released.

Yeah.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 07.05.2012 13:39, Dave Page wrote:
> On Mon, May 7, 2012 at 11:33 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>> for that matter. I'll fix this in git master. I consider the current tip of
>> the old CVS repository (or the corresponding checkout from the git repo) to
>> be the latest stable release, PostgreSQL one-click installers<= 9.1 can
>> continue to use that version.
>
> Can you create a "PRE-9_2" branch for the current architecture, and
> apply Ashesh's patch to that if you think it's a reasonable fix
> please? We can then move the older builds to that branch. Then the 9.2
> changes can go on master.

By current architecture, do you mean what we had in the CVS, or as the
code stands in the current tip of the git repository? I agree we should
create a branch like that, but I want to make sure we agree on where it
should be branched off. I've rearranged and cleaned up the code quite
extensively in git master already, and I'm not sure if we want to
include all that in back-branches. On one hand, I've fixed a lot of bugs
with the changes, so it would be nice to include those fixes, but OTOH,
perhaps we shouldn't risk destabilizing back-branches. Then again, we
can probably be more aggressive with pushing changes to pldebugger to
back-branches, as it's not something you should be running in production
anyway. It's just a development tool.

Correct me if I'm wrong, Ashesh, but your patch is only needed to fix
build issues I caused by rearranging the code and the Makefile in git
master. The code at the point where we migrated from CVS to git builds
fine on back-branches.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Mon, May 7, 2012 at 11:46 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 07.05.2012 13:39, Dave Page wrote:
>>
>> On Mon, May 7, 2012 at 11:33 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>
>>> for that matter. I'll fix this in git master. I consider the current tip
>>> of
>>> the old CVS repository (or the corresponding checkout from the git repo)
>>> to
>>> be the latest stable release, PostgreSQL one-click installers<= 9.1 can
>>> continue to use that version.
>>
>>
>> Can you create a "PRE-9_2" branch for the current architecture, and
>> apply Ashesh's patch to that if you think it's a reasonable fix
>> please? We can then move the older builds to that branch. Then the 9.2
>> changes can go on master.
>
>
> By current architecture, do you mean what we had in the CVS, or as the code
> stands in the current tip of the git repository? I agree we should create a
> branch like that, but I want to make sure we agree on where it should be
> branched off. I've rearranged and cleaned up the code quite extensively in
> git master already, and I'm not sure if we want to include all that in
> back-branches. On one hand, I've fixed a lot of bugs with the changes, so it
> would be nice to include those fixes, but OTOH, perhaps we shouldn't risk
> destabilizing back-branches.

What's at the current tip. I'm happy with those changes in the back
branches - they're really mostly just bug fixes and relatively minor
architectural tweaks as I understood them. It's the move to a single
library that I don't want in the back branches.

> Then again, we can probably be more aggressive
> with pushing changes to pldebugger to back-branches, as it's not something
> you should be running in production anyway. It's just a development tool.

Agreed.

Thanks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 07.05.2012 13:54, Dave Page wrote:
> On Mon, May 7, 2012 at 11:46 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> On 07.05.2012 13:39, Dave Page wrote:
>>> Can you create a "PRE-9_2" branch for the current architecture, and
>>> apply Ashesh's patch to that if you think it's a reasonable fix
>>> please? We can then move the older builds to that branch. Then the 9.2
>>> changes can go on master.
>>
>> By current architecture, do you mean what we had in the CVS, or as the code
>> stands in the current tip of the git repository? I agree we should create a
>> branch like that, but I want to make sure we agree on where it should be
>> branched off. I've rearranged and cleaned up the code quite extensively in
>> git master already, and I'm not sure if we want to include all that in
>> back-branches. On one hand, I've fixed a lot of bugs with the changes, so it
>> would be nice to include those fixes, but OTOH, perhaps we shouldn't risk
>> destabilizing back-branches.
>
> What's at the current tip. I'm happy with those changes in the back
> branches - they're really mostly just bug fixes and relatively minor
> architectural tweaks as I understood them. It's the move to a single
> library that I don't want in the back branches.

Ok. I created branch PRE_9_2, and committed Ashesh's patch there. In
master, I committed a patch to merge pldbgapi.so and plugin_debugger.so.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Mon, May 7, 2012 at 12:32 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 07.05.2012 13:54, Dave Page wrote:
>>
>> On Mon, May 7, 2012 at 11:46 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>>
>>> On 07.05.2012 13:39, Dave Page wrote:
>>>>
>>>> Can you create a "PRE-9_2" branch for the current architecture, and
>>>> apply Ashesh's patch to that if you think it's a reasonable fix
>>>> please? We can then move the older builds to that branch. Then the 9.2
>>>> changes can go on master.
>>>
>>>
>>> By current architecture, do you mean what we had in the CVS, or as the
>>> code
>>> stands in the current tip of the git repository? I agree we should create
>>> a
>>> branch like that, but I want to make sure we agree on where it should be
>>> branched off. I've rearranged and cleaned up the code quite extensively
>>> in
>>> git master already, and I'm not sure if we want to include all that in
>>> back-branches. On one hand, I've fixed a lot of bugs with the changes, so
>>> it
>>> would be nice to include those fixes, but OTOH, perhaps we shouldn't risk
>>> destabilizing back-branches.
>>
>>
>> What's at the current tip. I'm happy with those changes in the back
>> branches - they're really mostly just bug fixes and relatively minor
>> architectural tweaks as I understood them. It's the move to a single
>> library that I don't want in the back branches.
>
>
> Ok. I created branch PRE_9_2, and committed Ashesh's patch there. In master,
> I committed a patch to merge pldbgapi.so and plugin_debugger.so.

Thanks Heikki.

Ashesh; can you please update the back branch builds to use that
branch of the debugger code? Feel free to ask Dhiraj/Akshay/Dharam to
do it as I know you and Sachin are pretty busy right now.

Thanks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> Thanks Heikki.
>
> Ashesh; can you please update the back branch builds to use that
> branch of the debugger code? Feel free to ask Dhiraj/Akshay/Dharam to
> do it as I know you and Sachin are pretty busy right now.
>

Done.

>
> Thanks.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

--
Regards,
Sachin Srivastava
EnterpriseDB, India