I took a stab at compiling the new Greenfish Icon Editor Pro, which is now open source, in Lazarus IDE and it fails, unable to find a component called gfComp. Google and the Lazarus website are no help finding it. The source files will be downloadable here within about 10 minutes or so. We need to compile it ourselves as the publisher only offers the 64-bit version and we need both 32-bit and 64-bit for our users.
Note: Just for anyone thinking about grabbing 3.3 portable which includes the source, it is quite literally the worst installer I've ever seen. It has over a half dozen offers, all of which you have to decline, at least one of which attempts to then trick you with a popup. Even after declining all of them, it will shut down any running browsers on your system and refresh the Windows shell to reload icons. All that just to have the 'installer' download the zip file you should have gotten in the first place.
UPDATE NOTE: If you uncheck the silly 'Use our horrible downloader app' box under the Download button, it'll give you the actual Zip. Be sure to do that and spare yourself the pain I endured! 
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Is it possible to compile a 32-bit version within a 64-bit OS?
OS doesn't matter. I think the 64-bit Lazarus can compile both 32 and 64. If not, you can always install 32-bit Lazarus under 64-bit OS. I haven't checked. I was just going to ensure that 64-bit built properly first since that's what the publisher is doing.
Sometimes, the impossible can become possible, if you're awesome!
From what I've been able to figure out on Lazarus' site, you need to download both variants and do some fancy combining of the packages, similar to what we do for our packages, in order to cross-compile for 32-bit when on a 64-bit system.
I'll be having a go at it Tuesday.
[EDIT] I've downloaded both the source and the 32-bit variant of Lazarus, and have confirmed this error also occours on 32-bit systems, so it isn't a problem in the 64bit lazarus package.
I've reached out to the publisher for assistance, hopefully I'll hear back from him soon.
[EDIT2] And just like that, I got a reply.
There must be something else going on when compiling that I'm not aware of, as when I tried to compile, after removing that dependency, I had to recompile the gfiec dll in code:blocks, and was able to compile the app, but there were no languages, so the menus were all blank.
But, at least he added back at 32-bit variant, so we're able to push that out instead of compiling ourselves.
3.31 was posted and I'm compiling the source to ensure it's complete. Removed gfComp. Trying to compile and it "Can not find unit FastDiv used by bmExUtils".
Sometimes, the impossible can become possible, if you're awesome!
I ran into that as well. FastDiv.pas is in the Components folder, though.
I copied the files from Components to the parent directory and it compiled. It would not run due to missing libgfie64.dll, though.
Sometimes, the impossible can become possible, if you're awesome!
I figured that one out. You need to compile c\gfiec.cbp, ensuring to rebuild it with whatever compiler you have. I used MinGW. Note that once you get it compiled, GFIE will be missing the languages, so all the menus will be blank.
Compiled the gfiec.cbp dll both for 64 and 32 bits with discarding the -fomit-frame-pointer in release mode as this switch is implemented by default from -O and up, adding -fno-gcse -fno-guess-branch-probability to -march=i686 -O3 as these default switches can cause problems on non generic compiles, as I've experienced with gcc 4.6.1 and up, tested on some 200 million lines of C/C++ code.
The Fpc part also went clean out on Win32 -386 -O3 -OpPENTIUM4 -OoUncertain -CfSSE math, as there is P4rs without SSE3 out there.
smart linked with initial heapsize of 102400. and of course setting the path to the components dir. Done on Lazarus 1.1 fpc 2.6.3.
Execs tested on three Intel win boxes and running extremely fast and reliable at time of writing this.
As originally written works in over 99% of cases works with gcc, I amend that the dll src in this case disables the opening of gif files. Just discard -fno-guess-branch-probability and everything works just fine. Case two of several hundreds where I've detected this need for to guess the branch probability, in this case probably due to some fpc calling conventions.