# Port dependencies on libxul / libxul19



## Niatross (Dec 15, 2012)

I receive the following error when installing the icedtea-web-1.3.1 port:


```
icedtea-web is using libxul for gecko support, but you can
 change that by defining WITH_GECKO to the following values:

   libxul 
   libxul19 

===>  License GPLv2 accepted by the user
===>  Found saved configuration for icedtea-web-1.3.1
===>  Extracting for icedtea-web-1.3.1
=> SHA256 Checksum OK for icedtea-web-1.3.1.tar.gz.
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/perl5.14.2 - found

IMPORTANT: To build IcedTea-Web 1.3.1, you have to turn on 'ICEDTEA' option
for java/openjdk6 (default).  Otherwise, it will neither build nor work.

===>  Patching for icedtea-web-1.3.1
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/perl5.14.2 - found
===>  Applying FreeBSD patches for icedtea-web-1.3.1
/usr/bin/sed -i.bak -e 's|/usr/bin/perl|/usr/local/bin/perl|' /usr/ports/java/icedtea-web/work/icedtea-web-1.3.1/javac.in
/usr/bin/sed -i.bak -e 's|%%LOCALBASE%%|/usr/local|'  /usr/ports/java/icedtea-web/work/icedtea-web-1.3.1/launcher/javaws.in
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/zip - found
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/bash - found
===>   icedtea-web-1.3.1 depends on file: /usr/local/openjdk6/bin/java - found
===>   icedtea-web-1.3.1 depends on package: libxul>=10 - not found
===>   Found libxul-1.9.2.28_1, but you need to upgrade to libxul>=10.
*** Error code 1

Stop in /usr/ports/java/icedtea-web.
*** Error code 1

Stop in /usr/ports/java/icedtea-web.
```

The problem is this:

There are ports out there that "still" rely on "www/libxul19". If I upgrade to "www/libxul" (to make "icedtea-web-1.3.1" happy) then other ports that "still" rely on "www/libxul19" will not install. How do I get around this issue? It's a pain in the ass.


----------



## cpm@ (Dec 16, 2012)

Which port failed to install with www/libxul?


----------



## Niatross (Dec 16, 2012)

cpu82 said:
			
		

> Which port failed to install with www/libxul?



The "x11-toolkits/swt" port requires "www/libxul19" and will not build with "www/libxul"


----------



## cpm@ (Dec 16, 2012)

Try instead x11-toolkits/swt-devel. Take a look to this message.

Someone have advertised about this upgrade problem.


----------



## Niatross (Dec 16, 2012)

cpu82 said:
			
		

> Try instead x11-toolkits/swt-devel. Take a look to this message.
> 
> Someone have advertised about this upgrade problem.



Why are these ports (that rely on "www/libxul19") being ignored by the FreeBSD ports team?

Why are they ramming "www/libxul" down our throats before all the ports that rely on "www/libxul19" are upgraded to "www/libxul"?

Seems ass backwards to me.

Do they need help? Do they need more people to test the ports on the FreeBSD ports team?

The only way to fix this problem is to use "www/libxul19" (...since there are too many ports out there that "still" rely on it) and forget about "www/libxul" altogether.

Maybe one day we'll be able to use "www/libxul"...


----------



## cpm@ (Dec 16, 2012)

Next version should update all dependent ports to use www/libxul. Maintainers usually proceed in accordance with most important claimed messages.


----------



## Niatross (Dec 16, 2012)

cpu82 said:
			
		

> Next version should update all dependent ports to use www/libxul. Maintainers usually proceed in accordance with most important claimed messages.



I understand what your saying, but why not just hold off on the release of www/libxul and save the FreeBSD userbase the headaches. This is the "exact" reason (AKA: compiling errors) of why people run from FreeBSD and head for the hills. They don't want these headaches.

I love torture. That's why I'm still here.


----------



## cpm@ (Dec 16, 2012)

I think your posture is positive about it. In my humble opinion, all provisional solutions are really necessary in this case before big revisions. Good developers can fight this, but they need time to do a good work. Coordination of all code changes to be implemented, is a daunting task, but it should be the aim.


----------



## Niatross (Dec 16, 2012)

How can I tell portmaster to use the "www/libxul19" when compiling the java/icedtea-web port?

I could change the java/icedtea-web "Makefile" before using postmaster, but is their a way to override the following java/icedtea-web "Makefile" setting... using the portmaster command:


```
USE GECKO= libxul libxul19
```


----------



## cpm@ (Dec 16, 2012)

Niatross said:
			
		

> How can I tell portmaster to use the "www/libxul19" when compiling the java/icedtea-web port?
> 
> I could change the java/icedtea-web "Makefile" before using postmaster, but is their a way to override the "USE GECKO= libxul libxul19" setting (within the  java/icedtea-web Makefile) ....using the portmaster command?



Using portmaster(8) with --force-config option. Quoting from make(1):


> *-f makefile*
> 
> Specify a makefile to read instead of the default one.  If
> makefile is not an absolute pathname, make will search for it as
> ...



You have to define into the Makefile:

```
.if ${PORT_OPTIONS:MPLUGIN}
USE_GECKO=	libxul libxul19
USE_GNOME=	glib20 gtk20
USE_WEBPLUGINS=	native
WEBPLUGINS_DIR=	${PREFIX}/lib
WEBPLUGINS_FILES=IcedTeaPlugin.so
```

Or setting make variables in /etc/make.conf:

```
WITH_GECKO=libxul[B]19[/B]
```


----------



## Niatross (Dec 16, 2012)

You can't set "WITH_GECKO=libxul". I'm trying to use libxul19, not libxul.

libxul is for the birds. It doesn't work with a lot of ports. I explained this earlier. Read my posts above. Anyway, I'll just edit the makefile for "icedtea-web" and be done with it. I just though there might be an easier portmaster command that could overrride what's set in "Makefile".


----------



## cpm@ (Dec 16, 2012)

Niatross said:
			
		

> You can't set "WITH_GECKO=libxul". I'm trying to use libxul19, not libxul.
> 
> libxul is for the birds. It doesn't work with a lot of ports. I explained this earlier. Read my posts above. Anyway, I'll just edit the makefile for "icedtea-web" and be done with it. I just though there might be an easier portmaster command that could overrride what's set in "Makefile".



Sorry for my carelessness, but is better set variables in /etc/make.conf, check above, I corrected what you should add. For future problems with conflicts ports is preferable modify make.conf(5).


----------



## Niatross (Dec 16, 2012)

Thank you very much for your help on this.

I added the following to the /etc/make.conf file:


```
WITH_GECKO=libxul19
```

Do you know why the syntaxes between Makefile and make.conf are different:


```
[file]Makefile[/file] uses: USE_GECKO
[file]make.conf[/file] uses: WITH_GECKO
```


----------



## cpm@ (Dec 16, 2012)

Read this message for resolve your last question: http://www.mail-archive.com/freebsd-gecko@freebsd.org/msg02071.html.


----------



## SirDice (Dec 17, 2012)

Niatross said:
			
		

> Why are they ramming "www/libxul" down our throats before all the ports that rely on "www/libxul19" are upgraded to "www/libxul"?


Because www/libxul19 contains various security issues that will never be fixed.


----------



## Niatross (Dec 18, 2012)

SirDice said:
			
		

> Because www/libxul19 contains various security issues that will never be fixed.



I'm going to wait until all the ports have been upgraded to www/libxul. Once they are upgraded, then I'll move from www/libxul19 to www/libxul


----------



## SirDice (Dec 18, 2012)

Which ports would that be? I don't think there are a lot of ports that still depend on the old libxul19.


----------



## Niatross (Dec 19, 2012)

SirDice said:
			
		

> Which ports would that be? I don't think there are a lot of ports that still depend on the old libxul19.



See post #3. There are also many other ports out there that depend on libxul19.


----------



## SirDice (Dec 20, 2012)

I think somebody just needs to update that port. The version that's in the ports tree is 2, almost 3, years old. There's a 3.7.2 version that came out last February (looking at the releases it's quite possible there will be another new version next February). It's possible the dependency on the old libxul has already been fixed upstream.


----------

