Compiling Under Cygwin

Compile Bluefish for Cygwin

To make sure, you will not miss anything, we start at the beginning - the package selection during the the Cygwin installation. If you have a running system, it is possible, that you already have packages installed, we will need.

Step 1: Package selection

We need the following packages in addition to the packages, Cygwin wants to install by default. If you select a package, Cygwin sometimes will add some packages automatically because of existing dependencies:

• Admin section

 * cygrunsrv (necessary service, we will need to run Bluefish)

• Base section (all packages in this section should be installed by default)
• Devel section

 * ORBit2-devel
 * atk-devel
 * autoconf2.5
 * automake1.x (what you prefer, I suggest automake1.7)
 * binutils
 * bison
 * catgets
 * cvs (to checkout Bluefish from CVS)
 * gcc
 * gettext
 * gettext-devel
 * glib2-devel
 * gtk2-x11-devel
 * libbonobo2-devel
 * libfreetype2-devel
 * libxml2-devel (libxml2 contains xmllint)
 * make
 * minires-devel
 * openssl-devel
 * pango-devel
 * pcre
 * pcre-devel
 * pkgconfig

• Gnome section

 * gnome-vfs2
 * libgnome2
 * libgnomeui2 (optional)

• Interpreters section

 * python (optional)

• Libs section

 * popt

• Text section

 * aspell-dev
 * aspell-LANG (use a package for your language)

• Utils section (should all be optional)

 * bzip2 (if you prefer bzipped2 compressed archives)
 * desktop-file-utils
 * gnome-mime-data
 * shared-mime-info

• Web section

 * tidy (contains tidy binary)
 * wget (to grep a bluefish-source archive)

• X11

 * hicolor-icon-theme (optional)
 * xorg-x11-devel
 * xorg-x11-base, xorg-x11-bin, xorg-x11-bin-dlls, xorg-x11-fenc, xorg-x11-fnts (should be installed by default)
 * xorg-x11-fsrv (font-server, really necessary or you will receive errors from fontconfig)
 * xorg-x11-f100, xorg-x11-fcyr, xorg-x11-fscl (optional, but recommended)

Confirm your selection and Cygwin will install a base system and your selected packages.

Step 2: Downloading and compiling Bluefish

The compilation and installation is done in 3 steps (see the generic information in the Bluefish manual ). Start a Cygwin Bash Shell (START > Programs > CYGWIN > Cygwin Bash Shell OR the desktop icon) and create a directory, where you want to put the source:

$ mkdir bluefish && cd bluefish

Now you can use [1]] (see the instructions at [[DownloadingFromCVS CVS ] about working with CVS)

$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bluefish login
$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bluefish checkout bluefish-gtk2
$ cd bluefish-gtk2

or wget

$ wget ~http://pkedu.fbt.eitn.wau.nl/~olivier/downloads/bluefish-1.0.1.tar.gz
$ tar -xzf bluefish-1.0.1.tar.gz
$ cd bluefish-1.0.1

to get a release or snapshot. Now proceed with the compilation and installation (see the Manual for more info about possible configure options):

$ autoconf
$ ./configure ~[[your preferred options]]
$ make
$ make install

Now Bluefish is installed.

Step 3: Starting the cygserver service

Maybe you remember, we installed a package cygrunsrv in step 1. This service is necessary to ... To start it, first run

$ /usr/bin/cygserver-config

saying Yes to install cygserver as service. Then go to the START-Button of your Windows-box, choose Run (gives you a command-line), type cmd (for older Windows use ...) and hit ENTER. Now a Windows-Shell opens. We need to start the service with:

C:\WINDOWS\some\path> net start cygserver

The output sould tell you, if everything went ok. If you want to stop the service use: net stop cygserver (see also Start > Control Panel > Computer Administration > Services and Applications > Services : CYGWIN cygserver - set the startup-type for this service to Automatic and the service will be started with windows). Now you can close the Windows shell.

Step 4: Starting Bluefish

If everything went ok, you should now be able to start Bluefish. Start the X-Server

$ startx

and run Bluefish with

$ '''CYGWIN=server''' /usr/bin/bluefish.exe

The path and the executable-name depend on the configure options you used during compilation. The shown example used ./configure --prefix/usr for compilation. To not always have to type CYGWINserver, export the CYGWIN environment variable with your .bash_profile. Therefor add the line

export CYGWIN=server

to /home/yourusername/.bashprofile (sorry, the tilde sign cannot be shown in this Wiki).

Compiling bluefish cvs on cygwin issues

Some various answers I've collected so far to get bluefish cvs running on win32

---

From: Todd Fisher <toddf@simosoftware.com>

  You're running into a problem resulting in the difference between two

compilers. In linux by default all symbols are public (i.e. exposed) in win32 it's the opposite, all symbols are private (i.e. hidden). With msvc compiler you can use the 'declspec(dllexport) to expose symbols to the linker. With GCC you can use a combination of 'attribute' ((visibility(\"hidden\"))) for hidding symbols and 'attribute' ((visibility(\"default\"))) for exposing the symbols. A good starting place for understanding how this works in GCC since it is a new feature is to read the wiki here: http://gcc.gnu.org/wiki/Visibility

Now, on to your exact issue. You say the symbols are from the main application. I assume you mean you have a setup like the following:

main.c (depends on symbols from module.c) module.c (depends on symbols from main.c)

To fix your problem you'll want to make module.c not have dependencies on main.c . Or you'll have to force symbols to be exported from main.c which I believe you can do by using the /DLL flag for msvc... not sure about gcc in this case.

---

On Sun, 2005-10-30 at 19:24 +0100, David Necas (Yeti) wrote:

>>>> On Sun, Oct 30, 2005 at 05:43:21PM +0100, Tobias Kipfelsberger wrote: >>>>>>> > I have a plugin which is registered and loaded with the g_module

functions.

>>>>>>> > So far so good everything works find. >>>>>>> > But how can i let the modul access a function of the coreapplication? >>>>>>> > >>>>>>> > Example: >>>>>>> > in CoreApplication.h: >>>>>>> > >>>>>>> > GMODULEEXPORT void >>>>>>> > setCoreMenuAppbarText (const gchar* text) >>>>>>> > {} >>>>>>> > >>>>>>> > in plugin.c: >>>>>>> > >>>>>>> > #include \"CoreApplication.h\" >>>>>>> > void >>>>>>> > xyz () >>>>>>> > { >>>>>>> > setCoreMenuAppbarText(\"test\"); >>>>>>> > } >>>>>>> > >>>>>>> > as i execute the programm... i always get a undefined symbol error. > >> > >>>> >>>> You have to link the program with -export-dynamic (either as >>>> ld option, or libtool link option if you use libtool). >>>>

This is needed because by default the symbols defined in the main app are not made visible to the plugins. And the OP should be warned there is a good reason for the default.

If badly written plugins can call to the main application code they can easily make it look to the user as if your app code is broken. You should be prepared to handle the resulting support requests. Note, for example, the way the linux kernel team refuse to support bug reports from anyone running a \"tainted\" kernel.

If there is a well defined API you do want plugins to access, you can place the relevant code into a shared object of its own. Then you don't need to do anything special to protect it from Murphy's Law, since only the parts deliberately exposed can be accessed easily.

---

From: Tor Lillqvist <tml@iki.fi>

First, mark the functions in the sources for the main .exe that are to be used by other modules with GMODULEEXPORT.

Then you must decide whether you want to 1) restrict your plugins to work only with an executable with the exact name you specify, or whether you want it to be 2) more flexible and work even if you happen to rename the main executable.

In case 1), create an import library for the .exe using dlltool, and link the plugin against that import library.

In case 2), use gmoduleopen(NULL, 0) to get a GModule handle for the main executable, and the gmodulefind() the function from it, and call it.

---

From: Tor Lillqvist <tml@iki.fi> Iago Rubio writes:

>> It seems to me that's using gcc and GNU tools but ... >> How can it be done with the MSVC compiler ?

Use lib.exe instead of dlltool.