[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] [Fwd: Build glpk as a shared library on Cygwin, MinGW an

From: Jean-Pierre Flori
Subject: Re: [Help-glpk] [Fwd: Build glpk as a shared library on Cygwin, MinGW and similar systems]
Date: Wed, 12 Nov 2014 17:07:10 +0100


It appears my patches were completely broken anyway with a broken
if/else logic and a typo in an autotool var.
This is now fixed and confirmed to correctly work.
In case anyone cares, patches are attached here.


2014-11-05 10:17 GMT+01:00 Jean-Pierre Flori <address@hidden>:
> 2014-11-04 17:30 GMT+01:00 Marco Atzeri <address@hidden>:
>> On 11/4/2014 5:11 PM, Jean-Pierre Flori wrote:
>>> Hey,
>>> I agree, but they may also end up being passed to the linker.
>> Not that I am aware of. Libtool is correctly calling the linker.
> Sure, but some evil software mix libtool with direct calls to the
> compiler and linker.
>>> And some of them choke when given flags they don't recognize.
>>> IIRC I had this kind of issues with packages using gcc to link files.
>>> In fact, I just found the following of yours :)
>> It is the reason why in the patch that portion is at the end of the
>> otherwise it will be used by autoconf tests
> And that's the reason why using lib*_la_LDFLAGS can help.
> Of course it's not generic, so must be customized for each package and
> therefore requires more work.
> So it perfectly makes sense for someone maintaining a lot of cygwin packages.
> In case of one particular upstream project, the other solution can be safer.
> Please don't understand I say your solution is wrong, both have pros
> and cons, that's all.
> And as I said, as long as something gets merged into GLPK, I'll be happy.
> Best,
> --
> Jean-Pierre Flori

Jean-Pierre Flori

Attachment: cygwin_sharedlib_autoreconfed.patch
Description: Text Data

Attachment: cygwin_sharedlib.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]