PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

edwin ancaer
Hello,

I seem to have messed up some things again while upgrading from FreeBSD 11.0 to 11.1. Apparently, new versions of GNUstep-base (libgnustep-base.so.1.25) and GNUstep-gui (libgnustep-gui.so.0.25) were installed. This caused a reinstallation of all applications in the port x11/gnustep-app, but since then, ProjectCenter and Gorm stopped working. Eg. starting ProjectCenter retruns with the message object "libgnustep-base.so.1.24" not found, required by "ProjectCenter".
All other applications I tested seem to work correctly


When i do ldd ProjectCenter, both libgnustep-base.so.1.24 and libgnustep-base.so.1.25 are listed:

[edwin@ottopedi /usr/local/GNUstep/System/Applications/ProjectCenter.app]$ ldd ProjectCenter
ProjectCenter:
        libProjectCenter.so.0 => /usr/local/GNUstep/System/Library/Libraries/libProjectCenter.so.0 (0x28085000)
        libgnustep-gui.so.0.25 => /usr/local/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.25 (0x28400000)
        libgnustep-base.so.1.24 => not found (0)
        libobjc.so.4.6 => /usr/local/lib/libobjc.so.4.6 (0x28171000)
        libm.so.5 => /lib/libm.so.5 (0x28196000)
        libthr.so.3 => /lib/libthr.so.3 (0x281be000)
        libc.so.7 => /lib/libc.so.7 (0x281e1000)
        libgnustep-base.so.1.24 => not found (0)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x28340000)
        libicui18n.so.59 => /usr/local/lib/libicui18n.so.59 (0x28960000)
        libicuuc.so.59 => /usr/local/lib/libicuuc.so.59 (0x28bee000)
        libicudata.so.59 => /usr/local/lib/libicudata.so.59 (0x2834c000)
        libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x2834e000)
        libgnustep-base.so.1.25 => /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.25 (0x29000000)
        libgif.so.7 => /usr/local/lib/libgif.so.7 (0x28381000)
        libtiff.so.5 => /usr/local/lib/libtiff.so.5 (0x2838a000)
        libz.so.6 => /lib/libz.so.6 (0x28d85000)
        libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x28d9b000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x28e05000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x28e1e000)
        libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x28edc000)
        libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x28f39000)
        libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x28f44000)
        libgnutls.so.30 => /usr/local/lib/libgnutls.so.30 (0x294f1000)
        libxslt.so.1 => /usr/local/lib/libxslt.so.1 (0x28f53000)
        libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x2962a000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28f8b000)
        libffi.so.6 => /usr/local/lib/libffi.so.6 (0x283f7000)
        libkvm.so.7 => /lib/libkvm.so.7 (0x28fb1000)
        librt.so.1 => /usr/lib/librt.so.1 (0x28fbe000)
        libdispatch.so.0 => /usr/local/lib/libdispatch.so.0 (0x28fc3000)
        libjbig.so.2 => /usr/local/lib/libjbig.so.2 (0x28fd1000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28fdd000)
        libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x297a0000)
        libp11-kit.so.0 => /usr/local/lib/libp11-kit.so.0 (0x297e4000)
        libunistring.so.2 => /usr/local/lib/libunistring.so.2 (0x298b4000)
        libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x28fe6000)
        libnettle.so.6 => /usr/local/lib/libnettle.so.6 (0x29a36000)
        libhogweed.so.4 => /usr/local/lib/libhogweed.so.4 (0x29a6a000)
        libidn2.so.0 => /usr/local/lib/libidn2.so.0 (0x29a99000)
        libelf.so.2 => /lib/libelf.so.2 (0x29ab5000)
        libBlocksRuntime.so.0 => /usr/lib/libBlocksRuntime.so.0 (0x28ff8000)
        libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x28ffb000)



Does anyone have an idea might have gone wrong, and how I can I solve this? I already reinstalled the port, but the situation remains the same.

Thanks for any advice,

Edwin Ancaer

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

Riccardo Mottola-5

Hi,


On 04/11/2017 13:46, Edwin Ancaer wrote:
I seem to have messed up some things again while upgrading from FreeBSD 11.0 to 11.1. Apparently, new versions of GNUstep-base (libgnustep-base.so.1.25) and GNUstep-gui (libgnustep-gui.so.0.25) were installed. This caused a reinstallation of all applications in the port x11/gnustep-app, but since then, ProjectCenter and Gorm stopped working. Eg. starting ProjectCenter retruns with the message object "libgnustep-base.so.1.24" not found, required by "ProjectCenter".
All other applications I tested seem to work correctly


When i do ldd ProjectCenter, both libgnustep-base.so.1.24 and libgnustep-base.so.1.25 are listed:

I suppose you installed binary packages or in any case used ports?
Something is wrong in them for sure: they shouldn't be linked to both versions.

How did you perform your upgrade?

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

edwin ancaer
Hello,

I installed the ports with the make install command, in a previous version.


The update was done with the freebsd-update command. Then the problems started.

I also reinstalled all ports with the portmaster utility. It took my laptop over 24 hours to compile and install everything, but to no avail.

The weird thing is that all other apps are working correctly, so I wonder if I could have created a kind of desynchronization of the ProjectCenter en Gorm sources. Can I force a reload of the sources, to avoid using the local version?

Thanks already,

Edwin Ancaer






Op 4 nov. 2017 15:48 schreef "Riccardo Mottola" <[hidden email]>:

Hi,


On 04/11/2017 13:46, Edwin Ancaer wrote:
I seem to have messed up some things again while upgrading from FreeBSD 11.0 to 11.1. Apparently, new versions of GNUstep-base (libgnustep-base.so.1.25) and GNUstep-gui (libgnustep-gui.so.0.25) were installed. This caused a reinstallation of all applications in the port x11/gnustep-app, but since then, ProjectCenter and Gorm stopped working. Eg. starting ProjectCenter retruns with the message object "libgnustep-base.so.1.24" not found, required by "ProjectCenter".
All other applications I tested seem to work correctly


When i do ldd ProjectCenter, both libgnustep-base.so.1.24 and libgnustep-base.so.1.25 are listed:

I suppose you installed binary packages or in any case used ports?
Something is wrong in them for sure: they shouldn't be linked to both versions.

How did you perform your upgrade?

Riccardo


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

edwin ancaer
Sorry guys,


I seem to be filling this maillist with my stupidities.  I don't know what caused the original problem, but I should have noticed that the make install of Gorm and ProjectCenter did not trigger a compilation. Apparently, the works directory was owned by root, so once I did sudo make clean, it was properly deleted.

Everything works now.


I hope I manage to keep it this way

Op 4 nov. 2017 18:07 schreef "Edwin Ancaer" <[hidden email]>:
Hello,

I installed the ports with the make install command, in a previous version.


The update was done with the freebsd-update command. Then the problems started.

I also reinstalled all ports with the portmaster utility. It took my laptop over 24 hours to compile and install everything, but to no avail.

The weird thing is that all other apps are working correctly, so I wonder if I could have created a kind of desynchronization of the ProjectCenter en Gorm sources. Can I force a reload of the sources, to avoid using the local version?

Thanks already,

Edwin Ancaer






Op 4 nov. 2017 15:48 schreef "Riccardo Mottola" <[hidden email]>:

Hi,


On 04/11/2017 13:46, Edwin Ancaer wrote:
I seem to have messed up some things again while upgrading from FreeBSD 11.0 to 11.1. Apparently, new versions of GNUstep-base (libgnustep-base.so.1.25) and GNUstep-gui (libgnustep-gui.so.0.25) were installed. This caused a reinstallation of all applications in the port x11/gnustep-app, but since then, ProjectCenter and Gorm stopped working. Eg. starting ProjectCenter retruns with the message object "libgnustep-base.so.1.24" not found, required by "ProjectCenter".
All other applications I tested seem to work correctly


When i do ldd ProjectCenter, both libgnustep-base.so.1.24 and libgnustep-base.so.1.25 are listed:

I suppose you installed binary packages or in any case used ports?
Something is wrong in them for sure: they shouldn't be linked to both versions.

How did you perform your upgrade?

Riccardo


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

Riccardo Mottola-5
Hi,


On 04/11/2017 19:58, Edwin Ancaer wrote:
> I seem to be filling this maillist with my stupidities.  I don't know
> what caused the original problem, but I should have noticed that the
> make install of Gorm and ProjectCenter did not trigger a compilation.
> Apparently, the works directory was owned by root, so once I did sudo
> make clean, it was properly deleted.
>
> Everything works now.
>

Fine! I was to suggest something like this: for some reason those
packages weren't built and installed.
This was perhaps hidden by the fact that there isn't a new package
version of PC and you were doing a rebuild.
Good that you found it yourself!

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

David Chisnall
In reply to this post by edwin ancaer
On 4 Nov 2017, at 17:07, Edwin Ancaer <[hidden email]> wrote:
>
> I installed the ports with the make install command, in a previous version.
>
>
> The update was done with the freebsd-update command. Then the problems started.
>
> I also reinstalled all ports with the portmaster utility. It took my laptop over 24 hours to compile and install everything, but to no avail.

It’s worth noting that, while this may work, it is *strongly* discouraged on modern FreeBSD.  Ideally, you should be able to simply use the packaged versions (pkg ins gnustep-app).  If you do need to compile from source (e.g. if you need some custom options) then the recommended way to do so is to install Poudriere and use it to build a package set.

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

edwin ancaer
Well, the aim was to keep things simple and just use the packages, but along the road, discipline failed and I stared to use the ports for whatever reason. I suppose that being your own System Administrator is something that has to be learned too.

Does this make it useless to report 'bugs' I find on my system, until I do a  complete reinstall, as now there is a large possibility the causes are some local problems with my installation.

I'm asking because some apps seem to have problems when using the Rik-theme, and be OK with the traditional GNUstep theme, but I think I just  dowloaded the source for the Rik-theme and just installed it. (I understand now this must be even more horrible to a real FreeBSD-user than mixing ports and packages)

With Rik, Terminal.app for instance, displays the menu on top, but opens no window, with the following displays:

[edwin@ottopedi ~]$ openapp Terminal
2017-11-08 04:14:46.391 Terminal[1388:100275] styleoffsets ... guessing offsets
2017-11-08 04:14:46.392 Terminal[1388:100275] styleoffsets ... guessing offsets
2017-11-08 04:14:47.841 Terminal[1388:100275] File NSView.m: 1183. In -[NSView setFrame:] given negative width
2017-11-08 04:14:47.842 Terminal[1388:100275] File NSView.m: 1188. In -[NSView setFrame:] given negative height
2017-11-08 04:14:47.843 Terminal[1388:100275] NSFont <NSFont: 0x2c79ea00> DejaVu Sans Mono 12.000 0.000 0.000 12.000 0.000 0.000 S 0 info <CairoFontInfo: 0x2c776990> size 12 {x = 0; y = -9; width = 8; height = 9} 1
2017-11-08 04:14:47.981 Terminal[1388:100275] Problem posting notification: <NSException: 0x2c7c5d10> NAME:NSInvalidArgumentException REASON:[Rik-fillRect:withTiles:background:fillStyle:] rect width is not positive INFO:(null  )

When closing with the Quit option from the menu, I get a segmentation fault.
 
With the GNUstep theme, Terminal.app opens normally, and the displays after the start are:

[edwin@ottopedi ~]$ openapp Terminal
2017-11-08 04:22:02.797 Terminal[1539:100276] styleoffsets ... guessing offsets
2017-11-08 04:22:02.798 Terminal[1539:100276] styleoffsets ... guessing offsets
2017-11-08 04:22:03.489 Terminal[1539:100276] File NSView.m: 1183. In -[NSView setFrame:] given negative width
2017-11-08 04:22:03.490 Terminal[1539:100276] File NSView.m: 1188. In -[NSView setFrame:] given negative height
2017-11-08 04:22:03.491 Terminal[1539:100276] NSFont <NSFont: 0x2c542cb0> DejaVu Sans Mono 12.000 0.000 0.000 12.000 0.000 0.000 S 0 info <CairoFontInfo: 0x2c3f75d0> size 12 {x = 0; y = -9; width = 8; height = 9} 1


Thanks,

Edwin.

 


2017-11-07 12:06 GMT+01:00 David Chisnall <[hidden email]>:
On 4 Nov 2017, at 17:07, Edwin Ancaer <[hidden email]> wrote:
>
> I installed the ports with the make install command, in a previous version.
>
>
> The update was done with the freebsd-update command. Then the problems started.
>
> I also reinstalled all ports with the portmaster utility. It took my laptop over 24 hours to compile and install everything, but to no avail.

It’s worth noting that, while this may work, it is *strongly* discouraged on modern FreeBSD.  Ideally, you should be able to simply use the packaged versions (pkg ins gnustep-app).  If you do need to compile from source (e.g. if you need some custom options) then the recommended way to do so is to install Poudriere and use it to build a package set.

David



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

Bertrand Dekoninck



Le 08/11/2017 à 04:32, Edwin Ancaer a écrit :
With Rik, Terminal.app for instance, displays the menu on top, but opens no window, with the following displays:

[edwin@ottopedi ~]$ openapp Terminal
2017-11-08 04:14:46.391 Terminal[1388:100275] styleoffsets ... guessing offsets
2017-11-08 04:14:46.392 Terminal[1388:100275] styleoffsets ... guessing offsets
2017-11-08 04:14:47.841 Terminal[1388:100275] File NSView.m: 1183. In -[NSView setFrame:] given negative width
2017-11-08 04:14:47.842 Terminal[1388:100275] File NSView.m: 1188. In -[NSView setFrame:] given negative height
2017-11-08 04:14:47.843 Terminal[1388:100275] NSFont <NSFont: 0x2c79ea00> DejaVu Sans Mono 12.000 0.000 0.000 12.000 0.000 0.000 S 0 info <CairoFontInfo: 0x2c776990> size 12 {x = 0; y = -9; width = 8; height = 9} 1
2017-11-08 04:14:47.981 Terminal[1388:100275] Problem posting notification: <NSException: 0x2c7c5d10> NAME:NSInvalidArgumentException REASON:[Rik-fillRect:withTiles:background:fillStyle:] rect width is not positive <a class="moz-txt-link-freetext" href="INFO:(null">INFO:(null  )

When closing with the Quit option from the menu, I get a segmentation fault.

This is a know bug with themes that don't use standard tabs (Rik, Nesedah, Narcissus). The only workaround I've found is not to use tabs in Terminal.

You can change the ShowTabBar setting for Terminal with :

         defaults write Terminal ShowTabBar NO

But then don't open any new tab in Terminal or don't hit the #t and #T shortkeys again.
The latter one's are problematic because I often use #t in GWorkspace to open a new Terminal window.

I don't know if this bug is in Terminal itself or in gui. But I don't have any problem in GWorkspace for instance.

Maybe some smart fellow on this list could correct this bug. I'm not able to do this.

Cheers,
Bertrand Dekoninck

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

David Chisnall-4
In reply to this post by edwin ancaer
On 8 Nov 2017, at 03:32, Edwin Ancaer <[hidden email]> wrote:
>
> Does this make it useless to report 'bugs' I find on my system, until I do a  complete reinstall, as now there is a large possibility the causes are some local problems with my installation.

Generally, yes.  Part of the reason that it’s not recommended to build ports without using poudriere is that their configure scripts can end up polluted with installed things that are not explicit dependencies and then you can end up with a mess.  If you use poudriere, it will create a clean jail, install the dependencies, and then build, so you should end up with a more reproduceable build.  portmaster and portupgrade have a nasty habit of missing updates and leaving your system in a not-so-coherent state.  They also need you to install the dependencies before you build the ports that depend on them, which leaves you with a long window during a big update between the start and finish when you have mismatched versions.  With Poudriere, you kick off the build and then end up with a new package set at the end, which you can then install.

David

P.S. If you’re using 10.x and are able to see why cenon isn’t building on 10, that would be very helpful!
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

Ivan Vučica-2
In reply to this post by Bertrand Dekoninck


On Wed, Nov 8, 2017 at 8:59 AM, Bertrand gmail <[hidden email]> wrote:



2017-11-08 04:14:47.981 Terminal[1388:100275] Problem posting notification: <NSException: 0x2c7c5d10> NAME:NSInvalidArgumentException REASON:[Rik-fillRect:withTiles:background:fillStyle:] rect width is not positive INFO:(null  )


This is a know bug with themes that don't use standard tabs (Rik, Nesedah, Narcissus). The only workaround I've found is not to use tabs in Terminal.

Negative rect width seems pretty bad both on the side of -gui (should it throw an exception?) and on the side of the app (should it be causing things to create negative width rects?)


Something has been setting the width to negative before this exception.

 

You can change the ShowTabBar setting for Terminal with :

         defaults write Terminal ShowTabBar NO

But then don't open any new tab in Terminal or don't hit the #t and #T shortkeys again.
The latter one's are problematic because I often use #t in GWorkspace to open a new Terminal window.

I don't know if this bug is in Terminal itself or in gui. But I don't have any problem in GWorkspace for instance.

Maybe some smart fellow on this list could correct this bug. I'm not able to do this.

What did you try so far to track this down?

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

edwin ancaer
In reply to this post by David Chisnall-4
Well, I think it is important to have a standard setup when asking for help on the maillist.
J will do   a reinstall this weekend, and then use pkg install for all my installations.

For this cenon package, I don't mind giving it a try. Is it ok if I install 10.4?
And then I do pkg install xenon?

I'm currently on 11.1, and indeed, the package is installed, but the program is not working (on my non-standard installation):
[edwin@ottopedi ~]$ openapp Cenon
2017-11-09 02:59:10.141 Cenon[4708:100117] styleoffsets ... guessing offsets
2017-11-09 02:59:10.145 Cenon[4708:100117] styleoffsets ... guessing offsets
2017-11-09 02:59:10.260 Cenon[4708:100117] Unsupported... This is an XCode 5 XIB file.
2017-11-09 02:59:10.277 Cenon[4708:100117] Could not instantiate Xib unarchiver/Unable to parse Xib.
2017-11-09 02:59:10.281 Cenon[4708:100117] Failed to load Xib
2017-11-09 02:59:10.288 Cenon[4708:100117] Unsupported... This is an XCode 5 XIB file.
2017-11-09 02:59:10.304 Cenon[4708:100117] Could not instantiate Xib unarchiver/Unable to parse Xib.
2017-11-09 02:59:10.304 Cenon[4708:100117] Failed to load Xib
2017-11-09 02:59:10.307 Cenon[4708:100117] Cannot load the main model file 'Main'
2017-11-09 02:59:10.330 Cenon[4708:100117] Problem posting notification: <NSException: 0x2c6527d0> NAME:NSInvalidArgumentException REASON:-[NSFileManager createSymbolicLinkAtPath:withDestinationPath:error:]: unrecognized selector sent to instance 0x2a1a6f10 INFO:(null)





2017-11-08 11:08 GMT+01:00 David Chisnall <[hidden email]>:
On 8 Nov 2017, at 03:32, Edwin Ancaer <[hidden email]> wrote:
>
> Does this make it useless to report 'bugs' I find on my system, until I do a  complete reinstall, as now there is a large possibility the causes are some local problems with my installation.

Generally, yes.  Part of the reason that it’s not recommended to build ports without using poudriere is that their configure scripts can end up polluted with installed things that are not explicit dependencies and then you can end up with a mess.  If you use poudriere, it will create a clean jail, install the dependencies, and then build, so you should end up with a more reproduceable build.  portmaster and portupgrade have a nasty habit of missing updates and leaving your system in a not-so-coherent state.  They also need you to install the dependencies before you build the ports that depend on them, which leaves you with a long window during a big update between the start and finish when you have mismatched versions.  With Poudriere, you kick off the build and then end up with a new package set at the end, which you can then install.

David

P.S. If you’re using 10.x and are able to see why cenon isn’t building on 10, that would be very helpful!


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

edwin ancaer
In reply to this post by Ivan Vučica-2
Ivan, Bernard,

I could  have a look at it next week, after I reinstalled FreeBSD and GNUstep, if I manage to get lldb working.

Currently, lldb is just showing what i suppose to be the unicodes of the keys I press, but is not reacting to <ENTER>
[edwin@ottopedi ~]$ lldb38 Terminal.core
(lldb) target create "Terminal.core"
Current executable set to 'Terminal.core' (i386).
(lldb) \U+7A662\U+7A674\U+7A60A\U+7A60A\U+7A60A\U+7A60A\U+7A60A\U+7A60A\U+7A608\U+7A608\U+7A608

gdb does not seem to work with the core files from clang.

Mind you, I might have more questions than answers, being unexperienced with the tools.

Kind regards,

Edwin 


2017-11-08 22:31 GMT+01:00 Ivan Vučica <[hidden email]>:


On Wed, Nov 8, 2017 at 8:59 AM, Bertrand gmail <[hidden email]> wrote:



2017-11-08 04:14:47.981 Terminal[1388:100275] Problem posting notification: <NSException: 0x2c7c5d10> NAME:NSInvalidArgumentException REASON:[Rik-fillRect:withTiles:background:fillStyle:] rect width is not positive INFO:(null  )


This is a know bug with themes that don't use standard tabs (Rik, Nesedah, Narcissus). The only workaround I've found is not to use tabs in Terminal.

Negative rect width seems pretty bad both on the side of -gui (should it throw an exception?) and on the side of the app (should it be causing things to create negative width rects?)


Something has been setting the width to negative before this exception.

 

You can change the ShowTabBar setting for Terminal with :

         defaults write Terminal ShowTabBar NO

But then don't open any new tab in Terminal or don't hit the #t and #T shortkeys again.
The latter one's are problematic because I often use #t in GWorkspace to open a new Terminal window.

I don't know if this bug is in Terminal itself or in gui. But I don't have any problem in GWorkspace for instance.

Maybe some smart fellow on this list could correct this bug. I'm not able to do this.

What did you try so far to track this down?

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

David Chisnall
In reply to this post by edwin ancaer
On 9 Nov 2017, at 02:07, Edwin Ancaer <[hidden email]> wrote:
>
> Well, I think it is important to have a standard setup when asking for help on the maillist.
> J will do   a reinstall this weekend, and then use pkg install for all my installations.
>
> For this cenon package, I don't mind giving it a try. Is it ok if I install 10.4?
> And then I do pkg install xenon?

We’re currently not building packages for cenon on 10, because the build fails to install a nib file (which seems to be present in the source tarball, so no idea why not).  The same build works fine on 11.

> I'm currently on 11.1, and indeed, the package is installed, but the program is not working (on my non-standard installation):
> [edwin@ottopedi ~]$ openapp Cenon
> 2017-11-09 02:59:10.141 Cenon[4708:100117] styleoffsets ... guessing offsets
> 2017-11-09 02:59:10.145 Cenon[4708:100117] styleoffsets ... guessing offsets
> 2017-11-09 02:59:10.260 Cenon[4708:100117] Unsupported... This is an XCode 5 XIB file.
> 2017-11-09 02:59:10.277 Cenon[4708:100117] Could not instantiate Xib unarchiver/Unable to parse Xib.
> 2017-11-09 02:59:10.281 Cenon[4708:100117] Failed to load Xib
> 2017-11-09 02:59:10.288 Cenon[4708:100117] Unsupported... This is an XCode 5 XIB file.
> 2017-11-09 02:59:10.304 Cenon[4708:100117] Could not instantiate Xib unarchiver/Unable to parse Xib.
> 2017-11-09 02:59:10.304 Cenon[4708:100117] Failed to load Xib
> 2017-11-09 02:59:10.307 Cenon[4708:100117] Cannot load the main model file 'Main'
> 2017-11-09 02:59:10.330 Cenon[4708:100117] Problem posting notification: <NSException: 0x2c6527d0> NAME:NSInvalidArgumentException REASON:-[NSFileManager createSymbolicLinkAtPath:withDestinationPath:error:]: unrecognized selector sent to instance 0x2a1a6f10 INFO:(null)

Hmm, it looks as if no one has tested the latest upstream cenon release on GNUstep at all then - is anyone looking at adding XCode 5 xib support?  Does this depend on using the constraint-solving layout stuff (this shouldn’t be too difficult to add, I believe Apple uses a third-party LGPL library for the constraint solving - Nicolas Roard had some autolayout stuff using the same library about 10-15 years ago)?

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

Bertrand Dekoninck
In reply to this post by Ivan Vučica-2

> Negative rect width seems pretty bad both on the side of -gui (should
> it throw an exception?) and on the side of the app (should it be
> causing things to create negative width rects?)
>
> E.g the above exception originates from:
> https://github.com/gnustep/libs-gui/blob/master/Source/GSThemeTools.m#L506
>
> Something has been setting the width to negative before this exception.
>
>
>     You can change the ShowTabBar setting for Terminal with :
>
>              defaults write Terminal ShowTabBar NO
>
>     But then don't open any new tab in Terminal or don't hit the #t
>     and #T shortkeys again.
>     The latter one's are problematic because I often use #t in
>     GWorkspace to open a new Terminal window.
>
>     I don't know if this bug is in Terminal itself or in gui. But I
>     don't have any problem in GWorkspace for instance.
>
>     Maybe some smart fellow on this list could correct this bug. I'm
>     not able to do this.
>
>
> What did you try so far to track this down?

I've found this when the relevant code for tabs in Terminal was
introduced last year and told it to Riccardo. He answered me he couldn't
work on it, but that the code was pretty standard and it should have work.

For now, I can reproduce this bug with the 3 themes Rik, Nesedah and
Narcissus (as I told).

I had created the tabs in Rik using the same method as in Nesedah, so
they share the same way to handle them :
GSTabView*.png files are provided by these themes in their
"Resources/Theme Tiles" folder.  One possibility for the bug is a
missing file there. I'm not familiar enough with gui to tell.


The bug occurs when I open a tab in a Terminal already using the Rik theme.

One strange thing is  the following : Terminal with Rik can show one tab
in the tabbar if I switch the ShowTabBar option to YES in the menus And
it can show several tabs in the tabbar if the app was switched from the
GNUstep theme with the tabs already opened.


If I open a Terminal wiith the GNUstep theme, I've got these errors each
time I open a new window :

2017-11-09 09:29:21.083 Terminal[12463:12463] File NSView.m: 1183. In
-[NSView setFrame:] given negative width
2017-11-09 09:29:21.083 Terminal[12463:12463] File NSView.m: 1188. In
-[NSView setFrame:] given negative height
2017-11-09 09:29:21.083 Terminal[12463:12463] NSFont <NSFont: 0x1842a50>
Liberation Mono 16.000 0.000 0.000 16.000 0.000 0.000 S 0 info
<CairoFontInfo: 0x1842ae0> size 16 {x = 0; y = -11; width = 10; height =
11} 1

Then I can open a  tab and have this one  only :
2017-11-09 09:34:06.467 Terminal[12463:12463] NSFont <NSFont: 0x1842a50>
Liberation Mono 16.000 0.000 0.000 16.000 0.000 0.000 S 0 info
<CairoFontInfo: 0x1842ae0> size 16 {x = 0; y = -11; width = 10; height =
11} 1

And then, if I switch to Rik theme using the Info panel, no error
message is sent and the tabs are well displayed using Rik's tab images.
And Terminal works fine with them. I can change from the first tab to
second tab and all work. I can quit the app.

Finally, the next time I will open Terminal with Rik, the bug is there :
- if ShowTabBar is set to NO, a window is created, but if I open a tab,
the tabbar is created, the new tab isn't and the menus get stuck on the
"Default Shell" MenuTitle (the submenu isn't displayed). But I can
change to another top menu entry.
- if ShowTabBaris set to YES, no window is created at all and the menus
get stuck again.
- in both cases, I can go to the quit menu and quit Terminal. No core dump.

As I said,  Gworkspace works fine (tabs are used the the Desktop
preference pane). I don't know any other app using tabs so I don't know
if any other suffers from this bug.

Cheers Bertrand (not Bernard, Edwin  ;-) ).





_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: PrjectCenter (and Gorm) ask for old gnustep-base library in FreeBSD 11.1

Fred Kiefer
In reply to this post by David Chisnall


> Am 09.11.2017 um 08:16 schrieb David Chisnall <[hidden email]>:
>
> On 9 Nov 2017, at 02:07, Edwin Ancaer <[hidden email]> wrote:
>>
>> Well, I think it is important to have a standard setup when asking for help on the maillist.
>> J will do   a reinstall this weekend, and then use pkg install for all my installations.
>>
>> For this cenon package, I don't mind giving it a try. Is it ok if I install 10.4?
>> And then I do pkg install xenon?
>
> We’re currently not building packages for cenon on 10, because the build fails to install a nib file (which seems to be present in the source tarball, so no idea why not).  The same build works fine on 11.
>
>> I'm currently on 11.1, and indeed, the package is installed, but the program is not working (on my non-standard installation):
>> [edwin@ottopedi ~]$ openapp Cenon
>> 2017-11-09 02:59:10.141 Cenon[4708:100117] styleoffsets ... guessing offsets
>> 2017-11-09 02:59:10.145 Cenon[4708:100117] styleoffsets ... guessing offsets
>> 2017-11-09 02:59:10.260 Cenon[4708:100117] Unsupported... This is an XCode 5 XIB file.
>> 2017-11-09 02:59:10.277 Cenon[4708:100117] Could not instantiate Xib unarchiver/Unable to parse Xib.
>> 2017-11-09 02:59:10.281 Cenon[4708:100117] Failed to load Xib
>> 2017-11-09 02:59:10.288 Cenon[4708:100117] Unsupported... This is an XCode 5 XIB file.
>> 2017-11-09 02:59:10.304 Cenon[4708:100117] Could not instantiate Xib unarchiver/Unable to parse Xib.
>> 2017-11-09 02:59:10.304 Cenon[4708:100117] Failed to load Xib
>> 2017-11-09 02:59:10.307 Cenon[4708:100117] Cannot load the main model file 'Main'
>> 2017-11-09 02:59:10.330 Cenon[4708:100117] Problem posting notification: <NSException: 0x2c6527d0> NAME:NSInvalidArgumentException REASON:-[NSFileManager createSymbolicLinkAtPath:withDestinationPath:error:]: unrecognized selector sent to instance 0x2a1a6f10 INFO:(null)
>
> Hmm, it looks as if no one has tested the latest upstream cenon release on GNUstep at all then - is anyone looking at adding XCode 5 xib support?  Does this depend on using the constraint-solving layout stuff (this shouldn’t be too difficult to add, I believe Apple uses a third-party LGPL library for the constraint solving - Nicolas Roard had some autolayout stuff using the same library about 10-15 years ago)?

For this specific case the problem is even easier to solve. The GNUmakefile lists the XIB files where it should be using the NIB file. Just patch this file when packaging up Cenon.

Fred


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep