Re: [changeset] GraphicsMagick++ configuration

[Jaroslav Hajek]

On Tue, Aug 25, 2009 at 2:07 PM, David Grundberg<address@hidden> wrote:
> David Grundberg wrote:
>>
>> Thomas Weber wrote:
>>>
>>> On Sun, Aug 16, 2009 at 11:09:09PM +0200, Thomas Weber wrote:
>>>
>>>>
>>>> On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
>>>>
>>>>>
>>>>> On  6-Aug-2009, David Grundberg wrote:
>>>>>
>>>>> | John W. Eaton skrev:
>>>>> | > On  6-Aug-2009, David Grundberg wrote:
>>>>> | >
>>>>> | > | I've rearranged the GraphicsMagick++ configuration. I had some
>>>>> trouble | > | since I'm running a custom GraphicsMagick installation. The
>>>>> Octave build | > | system was running GraphicsMagick++-config during make.
>>>>> It was missing | > | ldflags and using only the basename of the config
>>>>> executable (as opposed | > | to a full path).
>>>>> | > | | > | I've changed it so that GraphicsMagick++-config is only run
>>>>> in the | > | configure script. Also introduced MAGICK_CONFIG as a precious
>>>>> variable.
>>>>> | >
>>>>> | > I removed --ldflags to fix the following mysterious problem on my
>>>>> | > system:
>>>>> | >
>>>>> | >
>>>>> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
>>>>> | >
>>>>> | > So I don't think I can put it back without breaking __magick_read__
>>>>> | > again, at least for me and other Debian users.
>>>>> | >
>>>>> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are
>>>>> those
>>>>> | > arguments not present on your system?  Maybe they are present on
>>>>> mine
>>>>> | > because of the way Debian builds the graphics magick library
>>>>> package?
>>>>> | > Perhaps these flags make sense for creating the graphics magick
>>>>> | > library itself, but I can't see any reason for them to be required
>>>>> to
>>>>> | > link the graphics magick library with __magick_read__.oct.
>>>>> | >
>>>>> | > jwe
>>>>> | >   | So that's why --ldflags was taken away! I don't have that
>>>>> problem. This | is the output from my config (where I'm building):
>>>>> | | $ |
>>>>> octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config
>>>>> | --ldflags --libs
>>>>> |
>>>>> -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib
>>>>> | -L/usr/lib -L/usr/lib
>>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper
>>>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm |
>>>>> -lgomp -lpthread
>>>>> | | My ubuntu 9.04 box says this about the managed package (haven't
>>>>> tried | building against it):
>>>>> | address@hidden:~$ GraphicsMagick++-config --ldflags --libs
>>>>> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib
>>>>> -L/usr/lib
>>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper
>>>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm |
>>>>> -lpthread
>>>>>
>>>>> So what should we do about this?
>>>>
>>>> These are different versions. The Ubuntu version is 1.1.11-something,
>>>> your Debian versions is 1.3.5-something.
>>>>
>>>>
>>>>>
>>>>> around it by filtering out everything except -L options from the
>>>>> --ldflags output, but I'd rather see it fixed in graphics magick.
>>>>> What should graphics magick really be storing in the config script
>>>>> for --ldflags?  Should options like -pie and -Wl,-z,relro really
>>>>> appear there?  Or is this just a Debian packaging problem?
>>>>>
>>>>
>>>> The Debian packaging adds the -pie and -Wl options when building
>>>> GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS into
>>>> its
>>>> --ldflags output. Looking at Ubuntu's build logs, the same is already
>>>> happening with newer versions of graphicsmagick.
>>>>
>>>> I'll ask the Debian maintainer of GraphicsMagick about it.
>>>>
>>>
>>> Okay, his answer is below. Short version: we should go we with
>>> pkg-config.
>>>
>>>
>>> ============================================================================
>>> Historically, the output of the *Magick*config scripts has been
>>> documented as
>>> the list of compiler/linker options *Magick was built with. This makes
>>> sense
>>> when build additional modules, but it's rather nonsensical for anything
>>> that
>>> just wants to link the C or C++ bindings. I recommend to use pkg-config
>>> for
>>> these kinds of applications instead. The hardening options aren't
>>> included
>>> there.
>>>
>>> ============================================================================
>>>
>>>    Thomas
>>>
>>
>> Thanks a lot for your help!
>>
>> I made a new changeset, attached to this mail.
>>
>> At first I tried the pkg-config setup and was disappointed to see (some
>> ubuntu):
>>
>> $ pkg-config GraphicsMagick++ --libs
>> -Wl,-Bsymbolic-functions -lGraphicsMagick++ -lGraphicsMagick $ pkg-config
>> GraphicsMagick++ --cflags
>> -I/usr/include/GraphicsMagick
>> But then I discovered the --libs-only-l/L arguments (didn't know about
>> these):
>>
>> $ pkg-config GraphicsMagick++ --libs-only-L
>>
>> $ pkg-config GraphicsMagick++ --libs-only-l
>> -lGraphicsMagick++ -lGraphicsMagick
>>
>> Nice.
>>
>> David
>
> (responding to self)
>
> Ooops. An invalid email address sneaked into the ChangeLog. Fixed it. Sorry
> for the noise.
>

I applied this, updating also src/oct-conf.h.in and src/toplev.cc,
which was necessary.

regards


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz