Build Windows version using MinGW?

[Team Prii]

I am trying to build FLTK-1.3.2 using MinGW. I installed the latest MinGW to the default C:\MinGW directory. In NetBeans IDE I added MinGW to the Tool Collections. Strangely the "mingw32-make.exe" is said to be incompatible with NetBeans and I had to manually change it to C:\MinGW\msys\1.0\bin\make.exe. (Actually initially NetBeans picked "C:\cygwin\bin\make.exe" and I changed it manually to "mingw32-make.exe".) Also strange is that there is no cmake under MinGW so NetBeans picked "C:\cygwin\bin\cmake.exe".

Using that setup I compiled muParserX and ran it under Windows without needing cygwin1.dll after adding "-static-libgcc -static-libstdc++" for the linker. So far so good.

Then I tried FLTK but got strange configuration errors:

configure:2846: checking for gcc
configure:2873: result: C:\MinGW\bin\gcc.exe
configure:3102: checking for C compiler version
configure:3111: C:\MinGW\bin\gcc.exe --version >&5
.\configure: line 3113: C:\MinGW\bin\gcc.exe: command not found
configure:3122: $? = 127
configure:3111: C:\MinGW\bin\gcc.exe -v >&5
.\configure: line 3113: C:\MinGW\bin\gcc.exe: command not found
configure:3122: $? = 127
configure:3111: C:\MinGW\bin\gcc.exe -V >&5
.\configure: line 3113: C:\MinGW\bin\gcc.exe: command not found
configure:3122: $? = 127
configure:3111: C:\MinGW\bin\gcc.exe -qversion >&5
.\configure: line 3113: C:\MinGW\bin\gcc.exe: command not found
configure:3122: $? = 127
configure:3142: checking whether the C compiler works
configure:3164: C:\MinGW\bin\gcc.exe -g3 -gdwarf-2 -mno-cygwin  -mno-cygwin  -mno-cygwin conftest.c  >&5
.\configure: line 3166: C:\MinGW\bin\gcc.exe: command not found

I looked in C:\MinGW\bin and the gcc.exe is there. Also NetBeans sees it too. What's going on?

[Greg Ercolano]

On 06/04/13 13:02, Team Prii wrote:
> .\configure: line 3113: C:\MinGW\bin\gcc.exe: command not found

This is a long shot, but from this window, can you paste the output of:

set

I want to see if there's something there that I've seen cause trouble.

Also, do you find that this command works..?

DIR C:\MinGW\bin\gcc.exe

..or does it say the file isn't found?

[Ian MacArthur]

No idea, beyond the obvious "something is borked in your paths" or some such...

What shell is that running in? I ask because the Msys shell that Mingw favour uses Posix rather than DOS paths, so those back-slashes might well be wrong... I dunno.

For what it's worth, I always install mingw/Msys and the Msys DTK, then build fltk in the Msys shell. That has been robust and reliable for ever.

The libs, once compiled, can the be used with whichever IDE you fancy...

[brian tilley]

I've only once tried to build in MinGW with Cygwin also installed on the PC.

The result was not good and I found that the Cygwin installation had added to the System PATH

This caused a lot of heartache for MinGW.

The good thing about MinGW is that it keeps all it's paths local to the shell envireonment.

 

Ian suggested something about the path to the compiler.

MinGW tends to use C:/MinGW/bin/ or /c/MinGW/bin/    paths

 

Like Ian, I recommend using the MSys shell (mintty terminal not rxvt)

Unpack the source tarball and then just cd to the top level source dir and type make.

But be aware that any Cygwin stuff in the System PATH may still cause aggro.

 

[Team Prii]

OK I will try to look for and use MSYS shell. Could someone please spell out the commands to build the FLTK library for static linking? (Sorry I am really not familiar with Unix command line stuff.) Thanks!

 

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/RaMl3HaaTNM/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[MacArthur, Ian (Selex ES, UK)]

> OK I will try to look for and use MSYS shell.
> Could someone please spell out the commands to
> build the FLTK library for static linking? (Sorry
> I am really not familiar with Unix command line stuff.)

There's a HowTo for that.

Admittedly, it is a bit dated (2006), but the mechanics are the same now as then...

http://www.fltk.org/articles.php?L598





Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Team Prii]

Thank you for the link! Yes it is old, at least the MinGW part is now much simpler with the GUI installer; just need to check the boxes for MSYS and its DTK.

The only issue I encountered during make was the "making documentation" part at the end; it says

/bin/sh: man: command not found

No big deal as I doubt I will ever look up the docs in MSYS shell.

I double clicked on demo.exe and got this:

libgcc_s_dw2-1.dll is missing

and running from within MSYS shell works. Now this reminds me of Cygwin. I don't understand why MinGW advertises as for building native Windows apps but it defaults to requiring MinGW/MSYS installed to run the app. It seems to me if they claim native Windows app then the app ought to be able to run by itself in a Windows system as is, without need the special gcc dll. At any rate I ran into the same problem earlier with muParserX and found on the web that adding
-static-libgcc -static-libstdc++

to the linker made the app work.

Now for linking to the FLTK library statically, do I need to modify the config process and re-make? If so, how? Or do I just need to add the same "-static-libgcc -static-libstdc++" to the linker later when I build my project? The goal is to make an exe file that can run on any Windows PC without having to have FLTK or MingGW installed. Thanks!

[MacArthur, Ian (Selex ES, UK)]

> Thank you for the link! Yes it is old, at least
> the MinGW part is now much simpler with the GUI
> installer; just need to check the boxes for MSYS
> and its DTK.

> The only issue I encountered during make was the
> "making documentation" part at the end; it says
> /bin/sh: man: command not found

Indeed, as you said, not an issue...

> I double clicked on demo.exe and got this:
> libgcc_s_dw2-1.dll is missing
> and running from within MSYS shell works.
> Now this reminds me of Cygwin. I don't understand
> why MinGW advertises as for building native Windows
> apps but it defaults to requiring MinGW/MSYS installed
> to run the app.

Ah, right: It doesn't require mingw installed.
What you are hitting there is a recent gcc-ism; note that the missing lib is a gcc lib, not a mingw lib.

What you need to do is re-run your configure, but do the configure command something like this:

(all one line, in an Msys shell...)

LDFLAGS="-static-libgcc -static-libstdc++" ./configure --enable-threads --enable-localjpeg --enable-localpng --enable-localzlib

The crux here is the bit that pre-sets an initial state for LDFLAGS, before it starts the configure script

(i.e. the LDFLAGS="-static-libgcc -static-libstdc++" bit...)

This tells gcc and gnu-ld that we want the static libgcc bits built into our code.

Thereafter, all should be well.

And yes, that'll hit any code you build with recent versions of gcc; hence the problems you flagged up with the parser code...

[Albrecht Schlosser]

On 05.06.2013 15:25, Team Prii wrote:

> Thank you for the link! Yes it is old, at least the MinGW part is now
> much simpler with the GUI installer; just need to check the boxes for
> MSYS and its DTK.
>
> The only issue I encountered during make was the "making documentation"
> part at the end; it says
> /bin/sh: man: command not found
> No big deal as I doubt I will ever look up the docs in MSYS shell.

Anyway, if you want to create the man pages:

$ mingw-get msys-man

> I double clicked on demo.exe and got this:
> libgcc_s_dw2-1.dll is missing
> and running from within MSYS shell works. Now this reminds me of Cygwin.
> I don't understand why MinGW advertises as for building native Windows
> apps but it defaults to requiring MinGW/MSYS installed to run the app.

Maybe it's the default, because you may build Windows apps that run
under MinGW/Msys and save some memory this way, but I don't know.

> It seems to me if they claim native Windows app then the app ought to be
> able to run by itself in a Windows system as is, without need the
> special gcc dll. At any rate I ran into the same problem earlier with
> muParserX and found on the web that adding
> -static-libgcc -static-libstdc++
> to the linker made the app work.

This would work here, too. This is the recommended way if you want to
distribute the application, and is okay WRT licensing (no GPL enforced,
but that wouldn't matter for you anyway).

> Now for linking to the FLTK library /*statically, */do I need to modify

> the config process and re-make? If so, how? Or do I just need to add the
> same "-static-libgcc -static-libstdc++" to the linker later when I build
> my project? The goal is to make an exe file that can run on any Windows
> PC without having to have FLTK or MingGW installed. Thanks!

Yes, you can do it this way. The preferred way (at least for me) is to
build the FLTK library using these flags, so that fluid and fltk-config
remember the flags, and you can use "fltk-config --ldflags" to help you
building your app.

There's more than one way to achieve this. Either you can export LDFLAGS
and run ./configure as usual, or you define LDFLAGS and run configure in
one command (line). Note that fltk-config will reflect the addition of
your flags when you run it later, no matter how you did it.

First option:

$ export LDFLAGS="-static-libgcc -static-libstdc++"
$ ./configure

Second option (that's what I do in a small script):

$ LDFLAGS="-static-libgcc -static-libstdc++" ./configure

This defines LDFLAGS only for running this single configure command and
leaves your environment as it is. That's why I prefer the latter.

Albrecht

[Team Prii]

Thank you both for the quick reply! So in summary I will do

LDFLAGS="-static-libgcc -static-libstdc++" ./configure --enable-threads --enable-localjpeg --enable-localpng --enable-localzlib

and then

make

Do I need to somehow clean up what's already done by the previous config and make?

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/RaMl3HaaTNM/unsubscribe?hl=en-US.

To unsubscribe from this group and all its topics, send an email to fltkgeneral+unsubscribe@googlegroups.com.

[MacArthur, Ian (Selex ES, UK)]

> So in summary I will do
>
> LDFLAGS="-static-libgcc -static-libstdc++" ./configure
> --enable-threads --enable-localjpeg --enable-localpng>
> --enable-localzlib
>
> and then
>
> make

Yes, sounds about right.

> Do I need to somehow clean up what's already done by the
> previous config and make?

Probably not; but to be on the safe side, you could always do a "make clean" before you re-run the configure script. That will force everything to be recompiled and linked the next time you do a make.

[Team Prii]

It worked! I can double click on fluid.exe and demo.exe and they start right up. Thank you!

For my own notes:

Start Menu - All Programs - MinGW folder - MinGW shell

cd to fltk-1.3.2_MinGW

make clean

LDFLAGS="-static-libgcc -static-libstdc++" ./configure --enable-threads --enable-localjpeg --enable-localpng --enable-localzlib

make

Oh this reminded me: am I supposed to be able to use the tab key to auto-complete partial file/directory names in the MinGW shell? That doesn't seem to work.

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/RaMl3HaaTNM/unsubscribe?hl=en-US.

To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.

[Albrecht Schlosser]

On 05.06.2013 19:29, Team Prii wrote:
> It worked! I can double click on fluid.exe and demo.exe and they start
> right up. Thank you!

Fine, that's good to know.

> Oh this reminded me: am I supposed to be able to use the tab key to
> auto-complete partial file/directory names in the MinGW shell? That
> doesn't seem to work.

Works for me with file and directory names, and also with commands
(executables) in $PATH. Doesn't work, however with command options like
"svn rev<tab>", which does indeed work with Cygwin/bash. ISTR that you
need to install a package name bash-completion or so to make *this*
work, but I never investigated this further.

Albrecht

[Ian MacArthur]

On 5 Jun 2013, at 18:29, Team Prii wrote:

> Oh this reminded me: am I supposed to be able to use the tab key to auto-complete partial file/directory names in the MinGW shell? That doesn't seem to work.

Seems to work OK for me...

Though I don't tend to use the default Msys shell all that much; it is really just some sort of tweaked DOS box, so far as I can tell.

Usually, I install the Msys mintty shell install, something like this:

mingw-get install mintty

(or something, nor sure of the actual package name, off the top of my head...)

Anyway, once mintty is installed, make a copy of the Windows shortcut that launches the stock Msys shell, then modify its properties tab to add "-mintty" to the launch invocation.

Thereafter that shortcut will launch a mintty shell instead; it is very much more flexible and configureable - right click on its window and you can set all manner of options there.

[Brian Tilley]

On 5 Jun 2013 20:27, "Ian MacArthur" <imaca...@gmail.com> wrote:
>
> On 5 Jun 2013, at 18:29, Team Prii wrote:
>
> > Oh this reminded me: am I supposed to be able to use the tab key to auto-complete partial file/directory names in the MinGW shell? That doesn't seem to work.
>
>
> Seems to work OK for me...
>
> Though I don't tend to use the default Msys shell all that much; it is really just some sort of tweaked DOS box, so far as I can tell.
>
> Usually, I install the Msys mintty shell install, something like this:
>
>    mingw-get install mintty
>
> (or something, nor sure of the actual package name, off the top of my head...)
>

The package is called msys-mintty
So use

mingw-get install msys-mintty

[Peter Åstrand]

On Wed, 5 Jun 2013, MacArthur, Ian (Selex ES, UK) wrote:

>> OK I will try to look for and use MSYS shell.
>> Could someone please spell out the commands to
>> build the FLTK library for static linking? (Sorry
>> I am really not familiar with Unix command line stuff.)
>
> There's a HowTo for that.
>
> Admittedly, it is a bit dated (2006), but the mechanics are the same now as then...
>
> http://www.fltk.org/articles.php?L598

Another possibility is to use CMake. Cross compilation on, say, Linux is
also possible. This is what we are doing. For reference, I'd like to share
the RPM spec file that we are using when building FLTK in our build
environment; attached. It uses some custom macros, but the principle
should be clear. As you can see, getting things right for all platforms is
pretty tricky... Minimizing our special patches and getting them
integrated upstream is a continous effort. As you can see, we support both
building with Autotools and CMake - this is so that we can verify that our
patches works with both toolchains. However, this causes some extra work.
I'd like to push for this STR:

Remove CMake or Autotools build system
http://www.fltk.org/str.php?L2916

If this bug is solved, that could simplify things a lot.

Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/112509906846170010689

[MacArthur, Ian (Selex ES, UK)]

Hi Peter,

> Minimizing our special patches and getting them
> integrated upstream is a continous effort.

Which flags up a point I'd like to raise with you: I think that we should see about giving you (or one of your people) developer access to the fltk repos; there are a fair number of good STR's raised up by your team, and no one is able to shepherd them thorough and get them committed into the mainline...

So, if you think that's a Good Idea, we should approach Greg (I assume he's holding the keys right now) about that, and get that sorted out.

From my perspective that would help us get a lot of your patches pushed through (many of which look like things I'd like to have!) and from your perspective it might alleviate some of the burden of maintaining a forked version?

Thoughts?

> As you can see, we support both
> building with Autotools and CMake - this is so that we can verify that
> our
> patches works with both toolchains. However, this causes some extra
> work.
> I'd like to push for this STR:
>
> Remove CMake or Autotools build system
> http://www.fltk.org/str.php?L2916
>
> If this bug is solved, that could simplify things a lot.

I think the STR is perhaps a little misleading, in that it doesn't quite reflect the "historical truth" of fltk's build system.

In reality, it is more like there are 3 build systems, and the building of the fltk lib has "traditionally" been done with autotools, or with the platform IDE's.
CMake support was (more or less) added as a user-contributed option, and has always been a little bit "unsupported".
I don't think any of the "core team" use CMake much if at all. (I'm too old for such things now!)

For my stuff, I use autotools to build fltk, on all the 3 platforms I have access to (W32, OSX, *nix), and then use Makefiles based on fltk-config (and occasionally pkg-config) for building my own app code (so my own code does not need autotools or CMake at all...)
(I acknowledge that my apps are probably a lot simpler to deploy than some!)

Cheers,
--
Ian

[Peter Åstrand]

Hi!

>> Minimizing our special patches and getting them
>> integrated upstream is a continous effort.
>
> Which flags up a point I'd like to raise with you: I think that we
> should see about giving you (or one of your people) developer access to
> the fltk repos; there are a fair number of good STR's raised up by your
> team, and no one is able to shepherd them thorough and get them
> committed into the mainline...
>
> So, if you think that's a Good Idea, we should approach Greg (I assume
> he's holding the keys right now) about that, and get that sorted out.
>
> From my perspective that would help us get a lot of your patches pushed
> through (many of which look like things I'd like to have!) and from your
> perspective it might alleviate some of the burden of maintaining a
> forked version?

This sounds great. Right now, we are busy with finalizing a product
release, but in a few weeks, we will have more time. One thing in
particular that we want to take a look at in the next development cycle is
our keyboard patches.

Pierre and I are working together on FLTK so it does not matter much if
you give me, him or both of us access; either way is fine.

>> As you can see, we support both
>> building with Autotools and CMake - this is so that we can verify that
>> our
>> patches works with both toolchains. However, this causes some extra
>> work.
>> I'd like to push for this STR:
>>
>> Remove CMake or Autotools build system
>> http://www.fltk.org/str.php?L2916
>>
>> If this bug is solved, that could simplify things a lot.
>
>
> I think the STR is perhaps a little misleading, in that it doesn't quite
> reflect the "historical truth" of fltk's build system.
>
> In reality, it is more like there are 3 build systems, and the building
> of the fltk lib has "traditionally" been done with autotools, or with
> the platform IDE's. CMake support was (more or less) added as a
> user-contributed option, and has always been a little bit "unsupported".
> I don't think any of the "core team" use CMake much if at all.

Yes, I understand the history, but we need to look forward as well. Having
things in the official releases which as "a little bit unsupported" is not
good. Things should be either fully supported, or not at all, in which
case the code should be moved to some kind of separate "contrib" tree or
similar.

I realize that different people use different systems. At some point,
there needs to be some migration "pain", when either Autotools or CMake
support is removed. The alternative is a sub-optimal situation forever.

I'm not in love with neither Autotools nor CMake, but both gets the job
done. CMake does have some advantages though, in that it can generate
Makefiles for many IDEs. It's also much faster on Windows.

> (I'm too
> old for such things now!)

I also thought that I was too old to learn CMake, but it was actually not
that difficult... :-)

> For my stuff, I use autotools to build fltk, on all the 3 platforms I
> have access to (W32, OSX, *nix), and then use Makefiles based on
> fltk-config (and occasionally pkg-config) for building my own app code
> (so my own code does not need autotools or CMake at all...) (I
> acknowledge that my apps are probably a lot simpler to deploy than
> some!)

App building should not be affected of whether CMake or Autotools is used
to build the FLTK library. In our product, we are also using a simple
Makefile in conjunction with fltk-config, and we did not have to change
anything at all when we switched to build FLTK with CMake.

[mjsurette]

As the user who originally contributed the CMake build, I'd like to weigh in on the CMake / autotools question.  You seem to like CMake, so let me rain on your parade.

It does make sense to have only one supported make system, with the other being set aside as contributed code. The logical choice for the official build system is autotools.  All the developers are used to it and it's the one they've known for years.  It's well tested and understood.

I wanted to cross-compile Windows binaries on Linux and to me autotools looked too much like black magic.  CMake looked much more manageable.  It was, as you say, easy to learn.  The devil is in the details, though.  There are a lot of details to keep organized in a project like fltk.  I did manage to get something that would do what I needed in Linux, and since I had Windows available too, I got that going.  The end result did what I wanted well enough.

The problem though is testing.  Personally, I tested it mostly under Linux with Windows being mostly an afterthought.  As for OSX, I couldn't tell you if it works at all, much less if it's robust.  I know Albrecht tested it, under Linux if my memory serves, before committing the code, but there is no way you could call it proven.  I would assume others have tried it just because it's there, but have no way of knowing if it worked or people just gave up on it.

CMake does have its advantages, but a proven system is hard to beat.  Looking forward, does CMake offer something that autotools doesn't which would be considered important enough to warrant the effort of a switch?

Mike

[Peter Åstrand]

On Tue, 11 Jun 2013, mjsurette wrote:

> As the user who originally contributed the CMake build, I'd like to
> weigh in on the CMake / autotools question.  You seem to like CMake, so
> let me rain on your parade.

To be honest, I'm not very found of neither Autotools nor CMake, but I
think it's important to select one approach and stick with that one. If
the conclusion is that Autotools is the best choice, I will not object.

But I do believe that CMake have some advantages:

> It does make sense to have only one supported make system, with the other being set aside as contributed code. The logical
> choice for the official build system is autotools.  All the developers are used to it and it's the one they've known for
> years.  It's well tested and understood.

These are all logical arguments, but there are several problems as well,
one being is that Autotools does not work well on Windows, ie does not
really fulfill all requirements/wishes. See
http://stackoverflow.com/questions/5837764/autotools-vs-cmake and
http://lwn.net/Articles/188693/, for example.

> I wanted to cross-compile Windows binaries on Linux and to me autotools looked too much like black magic.  CMake looked
> much more manageable.  It was, as you say, easy to learn.  The devil is in the details, though.  There are a lot of details
> to keep organized in a project like fltk.  I did manage to get something that would do what I needed in Linux, and since I
> had Windows available too, I got that going.  The end result did what I wanted well enough.
>
> The problem though is testing.  Personally, I tested it mostly under Linux with Windows being mostly an afterthought.  As
> for OSX, I couldn't tell you if it works at all, much less if it's robust.  I know Albrecht tested it, under Linux if my
> memory serves, before committing the code, but there is no way you could call it proven.  I would assume others have tried
> it just because it's there, but have no way of knowing if it worked or people just gave up on it.

Yes, some works needs to be done. OTOH, the current Autotools code is not
bullet proof either. As you could see in the .spec file we posted, there
are cross compilation issues.

> CMake does have its advantages, but a proven system is hard to beat.
>  Looking forward, does CMake offer something that autotools doesn't
> which would be considered important enough to warrant the effort of a
> switch?

I'd say that the fact that CMake works much better on Windows - both in
terms of functionality but also in performance - would warrant this
effort.


Rgds,

[Team Prii]

Back to the original question of building the FLTK library for static linking. I have followed this note:

Start Menu - All Programs - MinGW folder - MinGW shell
cd to fltk-1.3.2_MinGW

(make clean)

LDFLAGS="-static-libgcc -static-libstdc++" ./configure --enable-threads --enable-localjpeg --enable-localpng --enable-localzlib

make

make install

 

It works. However a question just popped up in my head: what is the resulting fltk.a library file like? Is it like an object file or a binary file? Does it contain the libgcc and libstdc++ inside? If so then later when I link a program with it and have the same flags, does the program end up with multiple copies of libgcc and libstdc++ inside?

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/RaMl3HaaTNM/unsubscribe?hl=en-US.

To unsubscribe from this group and all its topics, send an email to fltkgeneral+unsubscribe@googlegroups.com.

[Albrecht Schlosser]

On 26.07.2013 01:03, Team Prii wrote:
> Back to the original question of building the FLTK library for static
> linking. I have followed this note:
>
> Start Menu - All Programs - MinGW folder - MinGW shell
> cd to fltk-1.3.2_MinGW
> (make clean)
>
> LDFLAGS="-static-libgcc -static-libstdc++" ./configure --enable-threads
> --enable-localjpeg --enable-localpng --enable-localzlib
> make
> make install
> It works.

That's good.

> However a question just popped up in my head: what is the
> resulting fltk.a library file like? Is it like an object file or a
> binary file? Does it contain the libgcc and libstdc++ inside? If so then
> later when I link a program with it and have the same flags, does the
> program end up with multiple copies of libgcc and libstdc++ inside?

I assume you ask because of the LDFLAGS="..." usage. Short answer:
libfltk.a file is a normal object library, it contains (binary) object
files the linker (ld) can take to link with your own objects to an
executable (.exe) file (or alternatively to a shared library = dll).

The purpose of LDFLAGS is two-fold, but has nothing to do with the
format or contents of the object library itself:

(1) it is used to link fluid, so that you can use fluid w/o the
dependencies on libgcc and libstdc++, hence you can start it under
Windows as a "native" Windows program.

(2) all configure options are built into (or stored in) the fltk-config
shell script, so that for instance `fltk-config --ldflags' will show
these flags, and `fltk-config --compile' would use them to link your
programs.

[Team Prii]

Thank you! Just to make sure that I understand it correctly, the LDFLAGS does not affect the libfltk.a file, right?

In the comment (2), did you mean that "fltk-config --compile" can replace all the lines of commands in my note for building the package?

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/RaMl3HaaTNM/unsubscribe.

[Albrecht Schlosser]

On 26.07.2013 16:08, Team Prii wrote:
> Thank you! Just to make sure that I understand it correctly, the LDFLAGS
> does not affect the libfltk.a file, right?

Yes.

> In the comment (2), did you mean that "fltk-config --compile" can
> replace all the lines of commands in my note for building the package?

I'm not sure if I understand your question... trying to reply anyway.

Probably not. "fltk-config --compile" means executing the fltk-config
script to compile and link a single C++ file, something like
"hello.cxx". It does not help building the FLTK library - instead it is
a result of configuring the library. You should find it after you ran
./configure in the FLTK root directory and (if you installed fltk)
somewhere in your system directories (run fltk-config --prefix to find
out where the built FLTK library will be (or was) installed.

There are other options you can choose to help you building your own
executable programs after you built (and maybe installed) the FLTK
library files, see `fltk-config --help'. These commands can be used in
Makefile's, so that your Makefile can be platform-independent and also
independent of the options used when configuring the FLTK library. As an
example:

$ fltk-config --cxxflags
-I/fltk/svn/fltk-1.3 -I/fltk/svn/fltk-1.3/png -I/fltk/svn/fltk-1.3/zlib
-I/fltk/svn/fltk-1.3/jpeg -mwindows -DWIN32 -DUSE_OPENGL32
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE

For other options please see the help output mentioned above.

Note: we (the FLTK devs) recommend NOT to "install" FLTK after building,
since FLTK can be used directly from the build directory. This can help
to avoid having multiple versions of the library in your system. For
instance, you can use /path/to/fltk/fltk-config .. and this will work
using your fltk build directory.

[Team Prii]

Thank you!